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ABSTRACT 


The  German  Armed  forces  acquisition  guideline,  the  Customer  Product  Management 
(CPM),  regulates  the  principal  acquisition  process  steps  including  the  responsibilities 
between  civil  and  military  departments.  Many  of  the  CPM’s  specified  deliverables,  like 
formulating  needs,  writing  requirements  and  conducting  analysis,  are  created  and 
managed  by  military  personnel  that  are  assigned  to  support  the  acquisition  management. 
These  military  personnel  are  not  always  familiar  with  the  common  systems  engineering 
and  acquisition  methodologies  and  tools. 

The  capabilities  of  the  Gennan  armed  forces  are  derived  based  on  missions  and 
tasks.  The  variation  and  number  of  needed  capabilities  leads  to  a  greater  likelihood  of 
risk,  threat  and  funding.  ASW  missions  currently  are  no  longer  considered  primary 
capabilities  of  the  German  Navy.  The  ASW  ships  in  service  cannot  accommodate  the 
future  ASW  helicopter  (MH90),  which  will  cause  the  loss  of  utilization  of  this  primary 
warfighting  ASW  sensor  and  weapon.  On  the  other  hand  ships  without  any  ASW 
capabilities,  like  the  F125,  can  accommodate  ASW  helicopters.  This  dilemma  is  still 
unresolved  by  naval  leaders.  This  thesis  shall  examine  the  Gennan  basic  acquisition 
guidelines  and  present  applicable  systems  engineering  methodologies  and  tools 
considering  existing  regulations.  A  basic  systems  engineering  process  will  be 
demonstrated  using  a  possible  Gennan  Navy  next  generation  ship-borne  ASW-system 
through  the  presented  methodologies. 
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I.  INTRODUCTION 


A.  THESIS  BACKGROUND 

The  German  armed  forces  have  experienced  several  reduction  and  transformation 
processes,  and  the  last  transfonnation  process  of  the  forces  just  started  last  year  and  is 
intended  to  endure  until  2015.  As  an  outcome  of  the  transformation,  the  procurement  and 
acquisition  processes  and  guidelines  have  also  been  changed.  The  most  important  current 
guideline  is  the  Customer  Product  Management  (CPM)  and  it  regulates  the  principal  steps 
within  an  acquisition  program  and  the  responsibilities  between  civil  and  military 
departments.  In  the  German  armed  forces  no  US  DoD  5000  comparable  series  exists  to 
regulate  and  guide  programs  involving  civil  and  military  personnel.  Many  of  the  CPM’s 
specified  deliverables,  like  formulating  needs,  writing  requirements  and  conducting 
analyses,  are  created  and  managed  by  the  military  workforce.  Military  personnel  usually 
support  all  acquisition  processes  within  the  civil  procurement  agency  at  all  levels.  The 
Gennan  service  member  is  usually  not  familiar  with  the  most  well-known  methodologies 
and  tools  applicable  to  project  and  program  management. 

The  current  Gennan  Defense  Guidelines  (2011)  define  the  role  of  the  Gennan 
anned  forces  in  accordance  with  cunent  and  likely  future  threats.  The  capabilities  will  be 
adapted  with  respect  to  the  new  missions  and  tasks  (Gennan  Ministry  of  Defense,  2011). 
The  capabilities  of  the  Gennan  armed  forces  are  derived  from  its  missions  and  tasks.  The 
variation  and  number  of  needed  capabilities  impact  the  likelihood  of  risk,  threat  and 
funding. 

Anti-submarine  warfare  (ASW)  missions  are  currently  no  longer  considered  as 
primary  capabilities  of  the  Gennan  Navy.  The  ASW  ships  in  service  cannot 
accommodate  the  future  ASW  helicopter  (MH90)  due  to  their  limited  hangar  space.  This 
will  cause  the  loss  of  the  opportunity  to  deploy  these  ship  borne  aerial  ASW  sensors  and 
weapons.  On  the  other  hand,  ships  without  any  existing  ASW  capabilities,  like  the  FI 25, 
can  accommodate  ASW  helicopters.  This  dilemma  is  still  unresolved  by  naval  leaders. 
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B.  THESIS  OBJECTIVE 

The  objective  of  this  thesis  is  to  examine  basic  Gennan  acquisition  guidelines, 
namely  the  CPM,  and  present  systems  engineering  methodologies  and  tools  which  are 
applicable  within  the  German  military  acquisition  system  in  accordance  with  their 
regulations.  A  basic  systems  engineering  process  with  respect  to  a  possible  Gennan  Navy 
next  generation  ship  borne  ASW-system  shall  be  presented.  This  will  enable  an 
explanation  of  the  application  of  these  systems  engineering  methodologies  and  tools  in 
the  context  of  a  real  matter  of  concern,  and  will  simplify  the  demonstration  in  order  to 
provide  a  basis  to  understand  how  to  implement  a  systems  engineering  processes  in 
accordance  to  the  CPM. 

C.  RESEARCH  QUESTIONS 

The  thesis  shall  answer  the  question: 

Which  of  today’s  widely  recognized,  taught  and  applied  methodologies,  practices 
and  tools  used  in  military  acquisition  management,  and  in  particular  in  systems 
engineering,  apply  within  the  German  forces  acquisition  system  and  are  in  accordance  to 
regulations,  specifics,  guidelines? 

Furthermore,  the  thesis  shall  answer: 

Where  and  how,  within  the  acquisition  process,  do  they  fit  into  the  German 
acquisition  guidelines  to  fulfill  the  CPM’s  list  of  to-do  requirements? 

Additionally  the  thesis  shall  illuminate  and  clarify  the  basic  problem  of  a  possible 
need  for  a  next  generation  ship  borne  ASW-system  for  the  Gennan  Navy  ASW  ships. 

D.  SCOPE 

The  scope  of  the  thesis  is  limited  to  examining  the  Gennan  acquisition  guidelines 
with  respect  to  the  CPM’s  analysis  phases.  It  is  not  intended  to  deliver  a  comprehensive 
program  management  work  plan  and  detailed  report  structure.  The  thesis  scope  is  to 
research  the  systems  engineering  methodologies  and  apply  them  in  accordance  with  the 
CPM  only.  Therefore,  the  CPM  will  not  be  examined  on  “right  or  wrong”  approach,  ut 
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instead  present  options  for  what  could  be  altered  or  improved  in  the  German  acquisition 
process. 

The  ASW  problem  serves  mainly  as  a  story-board  to  present  the  methodologies  in 
an  adequate  and  understandable  way.  It  is  not  in  this  thesis’  scope  to  conduct  a  real  and 
comprehensive  systems  engineering  process  on  a  real  matter  which  delivers  credible 
detailed  numbers,  figures  and  facts  concerning  the  problem  in  order  to  draw  real 
conclusions.  The  ASW  problem  shall  only  illuminate  the  problem  on  a  basic  level,  since 
no  credible  data  are  available  and  the  extension  of  such  a  work  would  be  outside  the 
scope  of  the  single  person’s  thesis. 
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II.  BACKGROUND 


A.  GENERAL 

Since  the  reunification  of  Germany,  the  Gennan  armed  forces  have  experienced 
several  reduction  and  transfonnation  processes.  The  most  recent  transformation  process 
of  the  forces  started  last  year  and  is  intended  to  continue  until  2015.  In  2010  the  fonner 
Minister  of  Defense  zu  Guttenberg  initiated  a  comprehensive  refonn  of  the  Bundeswehr 
(that  is,  the  German  anned  forces  and  civil  departments  under  the  Ministry  of  Defense). 
The  main  goal  of  this  reform  effort  is  to  transform  the  armed  forces  into  a  smaller,  but 
more  modern  and  more  effective  force.  The  reform  effort  has  been  prompted  by  a 
demographic  issue:  the  unfavorable  ratio  of  young  to  old  people  in  the  next  few  years. 
Additionally,  the  economic  problems  that  began  in  2008  have  caused  a  more  restrictive 
federal  budget  currently,  while  future  budgets  will  be  constrained  by  the  legal 
requirement  to  limit  annual  federal  debts  to  3%  in  2016. 

The  starting  point  for  the  reform  of  the  Bundeswehr  was  a  report  produced  by  a 
commission  tasked  to  survey  the  current  situation  and  structure  of  the  Bundeswehr.  The 
report  of  the  Weise  Commission  (2010)  also  described  the  current  situation  of  the 
armament  process  in  the  Bundeswehr  and  says: 

The  previous  process,  based  on  the  Customer  Product  Management 

Guidelines  of  the  Bundeswehr,  has  been  approved  in  general,  but  there  are 

some  negative  attendant  circumstances. 

These  are  the: 


•  lack  of  a  capability  management  over  the  whole  procurement 
process, 

•  long  lasting  verification  and  decision  processes  by  concensus, 

•  rising  cost  of  procurement, 

•  opaque  processes  caused  by  fragmented  responsibilities  and  areas 
of  competencies  and  cumbersome  communication  structures. 

In  another  report,  the  Chief  of  Federal  Armed  Forces  Staff,  Volker  Wieker 

(2010),  criticized  the  whole  procurement  process.  Wieker  found  problems  with  the 

fragmented  responsibilities,  existing  procedures,  outside  influences  and  insufficient 
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funding.  Furthermore,  he  criticized  all  major  procurement  programs  for  failing  to  stay  on 
schedule,  for  exceeding  the  funded  budget  and  for  failing  to  deliver  the  requested 
capabilities.  Subsequently,  the  current  Minister  of  Defense  recommended  the 
restructuring  and  optimization  of  the  procurement  process  as  part  of  the  reform  of  the 
Bundeswehr. 

B.  THE  PROCUREMENT,  TEST  AND  EVALUATION  ORGANISATIONS  IN 

THE  BUNDESWEHR 

As  one  result  of  the  refonn  process  in  the  Gennan  Bundeswehr  the  new 
Bundesamt  fur  Ausriistung,  Informationstechnologie  und  Nutzung  der  Bundeswehr 
(BAAINBw,  Federal  Office  of  Bundeswehr  Equipment,  Infonnation  Technology  and  In- 
Service  Support)  has  been  established  from  the  former  Bundesamt  fur  Wehrbeschaffung 
(BWB,  Federal  Office  for  Military  Technology  and  Procurement).  All  Research  & 
Technology  activities,  the  procurement  and  acquisition  of  any  equipment  and  weapon 
systems,  as  well  as  management  during  the  usage  phase  are  the  responsibility  of  the 
BAAINBw,  a  civilian  controlled  federal  office  under  the  direction  of  the  Minister  of 
Defense. 

The  BAAINBw  is  in  charge  of  conducting  all  military  procurement  programs. 
Therefore,  a  project  manager  (PM)  of  the  BAAINBw  is  in  charge  the  program.  In  the  past 
the  project  manager  was  always  a  civilian  employee.  This  understanding  of  the  Basic 
Law  for  the  Federal  Republic  of  Germany  has  changed.  Today  the  important  aspect  is 
that  the  Federal  Office  of  Bundeswehr  Equipment,  Infonnation  Technology  and  In- 
Service  Support  is  part  of  the  civil  organizational  area  of  the  Bundeswehr  (see  Figure  1). 
Military  personnel  and  civil  servants  can  serve  in  this  office  and  become  project 
managers.  The  core  competencies  of  the  BAAINBw  are  development,  test  and 
evaluation,  and  procurement  of  military  equipment.  With  military  personnel  the  core 
competencies  have  been  extended  to  include  management  capabilities  for  the  usage  phase 
of  the  equipment  of  the  Bundeswehr.  The  test  and  evaluation  competency  lies  within  the 
responsibility  of  the  Wehrtechnische  Dienststellen  (WTD,  Defense  Technology 
Departments),  which  are  an  organizational  part  of  the  BAAINBw.  During  the 


6 


development  and  the  production  phases  as  well  as  for  already  introduced  and  procured 
equipment,  the  WTDs  test,  evaluate  and  certify  equipment  in  order  of  the  BAAINBw. 

In  particular  the  WTDs  are  responsible  for  the  following  tasks: 

•  test  and  evaluation  (procedure  of  proof) 

•  functional  support  of  all  weapon  systems  and  their  armaments 

•  certification  of  military  weapon  systems,  equipment,  and  armaments 

•  coordination  and  work  on  the  development  and  technology  program 
concerning  military  systems. 

WTDs  are  in  principle  only  tasked  with  development,  testing  and  evaluation 
(DT&E)  and  act  as  a  technology  specialist  within  the  Gennan  anned  forces.  The  WTDs 
are  not  tasked  with  any  operational  testing  and  evaluation  OT&E  activities.  OT&E 
activities,  according  to  the  Gennan  procurement  guidelines,  are  a  responsibility  of  the 
PM,  but  these  activities  are  conducted  by  the  user  (or  future  user)  of  any  weapon  system. 
The  Bundeswehr  has  no  comparable  agencies  to  those  in  the  U.S.  services.  Usually  a  lead 
unit,  such  as  the  first  unit  to  be  equipped  with  a  new  system,  or  a  weapon  school  is  tasked 
to  conduct  OT&E.  In  the  past,  many  schools,  especially  those  associated  with  the  anny 
and  the  joint  support  service,  had  a  department  for  concepts,  development  and  OT&E,  but 
with  the  new  structure  these  departments  are  often  eliminated. 
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C.  THE  GERMAN  MILITARY  PROCUREMENT  PROCESS 

In  October  2012  the  new  structures  were  implemented,  and  the  fonner  Federal 
Office  responsible  for  the  procurement  of  the  Bundeswehr,  the  BWB,  was  reestablished 
as  BAAINBw.  As  an  outcome  of  the  reorganization  and  transfonnation  the  processes  and 
guidelines  for  the  planning  and  armament  processes  have  been  changed  significantly.  The 
most  important  current  procurement  guideline  is  called  Customer  Product  Management 
(CPM),  and  it  regulates  the  principal  steps  within  a  procurement  program  as  well  as  the 
responsibilities  between  departments  of  the  MoD,  the  organizational  areas  and  the 
BAAINBw. 

Furthermore,  the  organization  structure  of  the  MoD  has  also  been  transformed, 
including  the  processes  of  monitoring,  analyzing,  and  planning  of  recognized  capability 
gaps  (need).  A  new  integrated  planning  process  (IPP)  (Bundesministerium  fur 
Verteidigung  2012)  has  been  developed  and  is  currently  in  implementation.  The  IPP 
regulates  inter  alia  the  processes  like  the  process  of  monitoring  and  analyzing  the 
political  strategic  settings,  developing  a  prioritized  capability  profile  and  analyzing 
existing  capabilities  against  this  prioritized  capability  profile.  This  process  will  be 
conducted  integrally,  which  means  that  aspects  and  issues  of  all  services  and  civil 
departments  will  be  taken  into  consideration  and  will  be  weighed  between  them. 

1.  Responsibilities  and  Order  of  Events  within  the  Procurement 

Processes  according  to  the  IPP 

The  capabilities  management  process  aims  to  recognize  capability  gaps  and  to 
derive  and  define  the  needs  of  the  forces,  and  is,  therefore,  an  important  and  necessary 
step  before  a  procurement  program  can  be  initiated.  This  process  is  called 
Geschaftsprozess  Fahigkeitsmanagement  (GP  FaMgmt,  capabilities  management 
process)  and  is  conducted  by  the  MoD,  the  Planungsamt  der  Bundeswehr  (PlgABw, 
Bundeswehr  Planning  Office),  BAAINBw,  and  by  the  services.  The  process  provides 
oversight  for  the  current  capability  position  of  the  Bundeswehr  and  enables  the  FaMgmt 
to  control  the  current  capability  position  (see  Figure  1). 
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Figure  1.  IPP:  Flow  diagram  control  of  capability  position  (Fahigkeitslage  fiihren). 

In  a  top-down  approach,  taking  external  settings  into  consideration,  needs  will  be 
derived  by  continuously  monitoring  and  analyzing  previously  determined  and  prioritized 
principle  capabilities,  which  are  necessary  to  fulfill  future  tasks.  In  a  second  step,  already 
existing  resources  and  capabilities  will  be  continuously  monitored,  analyzed  and 
displayed,  too.  The  results  identify  the  current  available  capabilities  (see  Figure  2). 
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Figure  2.  IPP:  Conduct  analysis  of  capability  (Fahigkeitsanalyse  durchfiihren). 


Both  results  (that  is,  the  recognized  needs  and  the  current  capabilities)  will  be 
pictured  through  the  current  capability  position  that  allows  an  identification  of  a 
capability  gap  and  the  derivation  of  a  need  (see  Figure  3). 


Figure  3.  IPP:  Adaption  of  the  capability  profile  (Fahigkeitsprofil  anpassen). 
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The  recognized  need  will  be  thoroughly  analyzed  and  assessed  in  respect  to  its 
significance.  If  the  capability  gap  is  deemed  unacceptable  and  an  appropriate  financial 
framework  is  available,  further  steps  within  the  process  will  be  induced  and  measures 
initiated  to  offset  the  need.  When  it  is  possible  to  satisfy  the  need  with  a  material 
solution,  then  the  PlgABw  sets  up  an  IPT.  The  PlgABw  has  leadership  over  the  IPT  and 
will  be  supported  by  personnel  resources  from  other  federal  offices  and  all  services.  The 
IPT  is  responsible  for  drawing  up  the  CPM  document,  “Fahigkeitsliicke  und  Funktionale 
Forderung”  (FFF,  capability  gap  and  functional  requirements).  This  document  describes 
the  capability  gap  and  develops  functional  requirements  concerning  the  need. 


When  the  FFF  is  approved,  the  next  step  within  the  process  is  to  develop  different 
solutions  and  to  prepare  a  selection  decision  of  the  proposed  alternatives  (see  Figure  4). 


Figure  4.  IPP:  Prepare  selection  decision  (Auswahlentscheidung  vorbereiten). 

A  level  A  or  B  project  (projects  with  superordinate  importance,  like  major 
weapon  systems)  will  be  in  principle  decided  by  the  Chief  of  Federal  Anned  Forces  Staff. 
All  other  projects  will  be  decided  by  the  PlgABw. 

If  a  decision  in  favor  of  one  alternative  is  approved  and  funded,  then  the  solution 
will  be  implemented  as  a  program  by  the  BAAINBw.  A  program  manager  and  his  IPT 
are  in  charge  of  the  program,  which  must  be  conducted  according  the  CPM  guidelines. 
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2.  The  Procurement  Processes  According  to  the  CPM  Guidelines 


As  an  outcome  of  the  transformation  the  procurement  processes  and  guidelines 
have  been  changed.  The  most  important  current  guideline  is  called  Customer  Product 
Management  (CPM),  and  it  regulates  the  principal  steps  within  an  acquisition  program, 
the  responsibilities  between  departments  as  well  as  between  the  forces  and  the 
BAAINBw.  The  Customer  Product  Management  (CPM)  is  an  MoD  internal  guideline 
concerning  the  need-investigation,  need-cover,  and  utilization/in-service  support 
processes  of  any  weapon  systems  in  the  German  armed  forces.  As  soon  as  a  materiel 
solution  is  determined  by  the  PlgABw  and  approved  by  the  MoD  for  cases  with  high 
priority,  the  PlgABw  conducts  the  previously  described  FFF  process,  which  is  the  first 
part  of  the  analysis  process.  After  the  FFF  is  approved  by  the  Chief  of  Federal  Armed 
Forces  Staff,  the  leadership  of  a  program  changes  from  PlgABw  to  the  BAAINBw,  which 
has  to  develop  at  least  three  alternative  solutions  according  to  the  FFF  functional 
requirements.  This  is  the  second  part  of  the  analysis  process  that  presents  the  actual 
initiation  of  a  procurement  program  (see  Figure  6). 


1.  Einhindiimj  f.ichliche  Expertise  pot.  Nutzei  Betieiher 

2.  zukunfthjei  Nutzei  Betieibei 

3.  Befehlshtiliei  Inspekteui 


(^)  ipt  Integriertes  Projektteam 


Figure  5.  CPM:  Schematic  order  of  sequence  of  a  procurement  program. 

When  an  alternative  solution  is  eventually  selected,  approved,  and  funded  by  the 
MoD,  the  aforementioned  IPT  is  again  in  charge  of  implementing  the  approved  solution 
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and  introducing  the  product.  The  IPT  will  also  be  responsible  for  all  of  the  product’s  life- 
cycle  issues.  The  composition  of  the  IPT  will  be  adjusted  during  a  program  as  illustrated 
in  Figure  5. 


a.  Analysis  Phase 

The  first  part  of  the  analysis  phase  aims  for  identification  of  capability 
gaps  and  prioritization  of  measures  to  close,  reduce  or  even  accept  a  gap.  If  a  gap  has  to 
be  closed,  then  all  possibilities  to  close  it  will  be  analyzed  and  documented.  This  includes 
changes  in  organization,  in  personnel  and  training,  in  infrastructure,  as  well  as  in 
improvements  in  maintenance  and  use  of  materiel  solutions.  Only  materiel  solutions  are 
covered  by  the  CPM  process.  When  a  materiel  solution  is  requested,  then  the  IPT  has  to 
work  out  an  FFF.  An  incorporation  of  experience  and  knowledge  is  required,  with 
particular  consideration  concerning: 

•  deployments 

•  allies  and  partners 

•  operation  and  maintenance 

•  products  already  existing,  available  or  in  development  (COTS; 

CGM) 

•  international  procurement  cooperation 

•  results  from  research  and  development  (R&D) 

•  results  from  research  papers 
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The  FFF  describes  the  capability  gap  and  the  functional  requirements. 
Additionally  the  following  information  shall  be  included: 

•  designation  of  the  required  capability  (need) 

•  extrapolation  of  the  capability  from  reference  documents  and  a 
description  of  capability  gap  in  the  system  context  of  the 
Bundeswehr 

•  description  of  the  functional  requirements  and  project  elements 

•  information  about  time-frame  and  life-cycle  costs 

•  information  about  amount,  duration  of  usage,  and  future  users 
/operators 

•  financial  requirements  for  the  analysis  phase 

•  detennination  if  fundamental  national  interest  is  concerned 

The  FFF  shall  in  principle  be  able  to  develop  solutions  that  may  consider 
commercial  products  and  components.  It  shall  not  anticipate  any  technical  solutions. 
Only  an  approved  FFF  frees  funding  for  R&D  for  the  second  part  of  CPM’s  analysis 
phase. 


The  second  part  of  the  analysis  phase  contains  the  development  of  an 
alternative  solutions  proposal.  The  solutions  can  be  differentiated  in  already  available 
products  and  services,  improvement  of  “in-service”  systems,  and  development  of  new 
products.  The  IPT,  under  the  direction  of  the  BAAINBw,  has  to  provide  at  least  one 
solution  that  meets  all  the  functional  requirements  as  well  as  other  solutions  that  meet  at 
least  the  time  and  cost  frame  of  the  FFF. 

The  following  tasks,  among  others,  need  to  be  conducted  within  this 

phase: 

•  perfonn  market  surveys  and  assessments  of  available  products  and 
services 

•  analyze  and  assess  possible  improvement  of  “in-service”  systems, 
possible  national  and  international  cooperation  and  possible 
development  of  new  products 

•  show  risks  and  impact  on  procurement  and  operation  of  a  system 

•  detennine  amount  and  life-cycle  costs  and  economic  analysis 
(efficiency) 

•  predict  time  frame  and  financial  funding  for  procurement  and 
operation 
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•  assess  effectiveness  of  the  functional  requirements  with  respect  to 
quality  and  quantity 

•  plan  the  procurement  and  operation  phase 

Possible  solutions  are  analyzed  and  assessed  against  the  background  of 
perfonnance,  time,  costs,  and  risk.  Findings  derived  from  technical  assessments  of  the 
defense  systems  of  other  nations  will  also  be  considered.  The  proposed  solutions  must 
contain  following  infonnation: 

•  the  demand  amount 

•  the  quality  and  quantity  of  the  requirement  fulfillment 

•  the  time  and  cost  requirements 

•  the  costs  for  operations  (including  personnel,  infrastructure,  etc.) 

•  the  operating  efficiency  over  the  life-cycle 

•  a  defense  economic  and  political  assessment 

•  a  risk  assessment 

The  proposal  of  all  alternative  solutions  will  be  presented  to  the  Chief  of 
the  Federal  Anned  Forces  Staff  (CoS)  by  the  MoD  Directorate  of  Equipment, 
Infonnation  Technology  and  In-Service  Support.  The  CoS  decides  which  solution  will  be 
selected  and  continued  as  a  procurement  program. 

b.  Product  Realization  Phase 

This  phase  of  the  CPM  is  intended  to  provide  a  product  and/or  service  that 
is  suitable  in  time  and  operational  mature.  The  work  processes  and  activities  in  this  phase 
describe  the  principal  responsibilities  and  deliverables  concerning  the  program  manager 
(PM).  The  CPM  relies  solely  on  the  professional  expertise  of  the  members  of  his  IPT, 
who  must  deliver  the  preliminary  work  and  bear  the  brunt  of  the  program  workload. 

When  the  Zielvereinbarung  (ZV,  the  agreement  on  objectives)  is  signed  by 
the  MoD  and  BAAINBw  no  changes  of  already  agreed  upon  requirements  within  the 
program  process  are  allowed.  Exceptions  for  changes  are  justified  only  if  new 
experiences  and  knowledge  derived  from  deployments  or  other  “disturbances”  within  the 
program  process  arise  that  lead  to  an  exceeding  of  predefined  parameters.  Such 
conditions  would  cause  an  adaption  in  performance,  costs,  and  schedule. 
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Another  CPM  highlighted  issue  is  the  Integrierte  Nachwcisfuhrung 
(integrated  compliance  demonstration)  during  the  realization  phase.  It  concerns  all  the 
proofs  and  documents  delivered  through  the  contractor,  as  well  as  the  evaluation  of 
product  parameters,  operational  test  and  functional  limits.  The  product  will  be  handed 
over  to  the  designated  operational  user  only  when  operational  testing  is  successfully 
conducted  according  FFF.  This  task  to  establish  operational  viability,  capability  and 
readiness  is  also  part  of  the  responsibility  of  the  PM  in  the  BAAINBw.  During  the 
proofing  procedure  any  shortcomings  will  be  identified  and  taken  into  consideration. 

c.  Operational  Phase/ In-Service  Phase 

After  a  successful  product  delivery,  the  responsibility  to  maintain  the 
product’s  operational  viability,  capability  and  readiness  still  lies  with  the  BAAINBw  and 
the  IPT. 

The  Director  of  the  Federal  Office  of  Bundeswehr  Equipment,  Information 
Technology  and  In-Service  Support  has  “material  responsibility  for  operational  viability” 
over  the  whole  usage/in-service  phase  until  the  retirement  of  the  product.  Some  of  the 
ongoing  tasks  are  product  improvement,  obsolescence  management,  operations  data 
analysis  concerning  maintenance,  and  software  maintenance  and  improvements. 
However,  the  “daily”  operational  responsibility,  like  providing  spare  parts  or  perfonning 
line  maintenance,  changes  over  to  the  services. 

d.  Summary 

The  acquisition  and  procurement  phases  of  the  CPM  shows  a  today  typical 
structure  and  in  many  respects  comparable  to  the  US  DoD  5000  series,  but  gives  just  a 
guideline  on  a  top-level.  More  detailed  guidance  how  to  conduct  the  phases  are  not 
available  and  could  be  supported  by  systems  engineering  methodologies  and  tools. 
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III.  WHY  SYSTEMS  ENGINEERING  IS  CRUCIAL  IN  MILITARY 

PROCUREMENT 


A.  INTRODUCTION 

The  IPT’s  composition  according  to  CPM  involves  mostly  the  military  workforce. 
Military  personnel  typically  support  all  acquisition  processes  within  the  civil  procurement 
agency  at  all  levels,  but  its  members  receive  only  a  three-week  education  in  program 
management  concerning  the  regulations  according  to  the  CPM.  Military  personnel 
involved  in  procurement  usually  serve  in  forces  command  as  well  as  in  the  logistics  and 
materiel  offices.  Its  members  may  also  have  experience  as  pilots  or  maintenance 
personnel.  The  Gennan  service  member  is  not  familiar  with  most  well-known  practices 
and  tools  applicable  to  project  management.  As  a  result,  and  due  to  the  absence  of  more 
detailed  acquisition  regulations  and  guidelines,  many  important  acquisition  programs 
were  often  inefficient  or  unsuccessful  in  the  past. 

Applying  knowledge  and  tools  appropriate  to  military  program  management  can 
help  to  avoid  getting  bad  products.  The  existing  tools  in  program  management  are  not 
simply  derived  from  one  or  two  research  disciplines,  rather  the  tools  come  from  a  wide 
range  of  research  areas  of  business  and  engineering.  Simulation  and  modeling,  supply- 
chain  management,  logistics  engineering,  decision  making,  cost-benefit  analysis,  testing 
and  evaluation,  quality  management  and  management  soft-skill  disciplines  are  just  some 
of  the  areas  from  which  the  tools  are  derived.  Meanwhile  this  indispensable  and 
necessary  knowledge  about  the  methodologies  and  tools  makes  program  management  in 
military  acquisition  very  comprehensive  and  complex  work. 

Systems  engineering  is  already  a  proven  work  process  that  is  well  established  and 
widely  used  in  the  industry.  Systems  Engineering  Design  Processes  (SEDP)  support 
understanding  a  problem  before  proposing  solutions,  examining  alternative  potential 
solutions  and  verifying  the  correctness  of  proposed  solutions.  SEDP  must  also  consider 
the  delivery  of  solutions  within  the  constraints  of  a  project.  The  INCOSE  handbook 
(Haskins,  Forsberg, Krueger  2010)  describes  systems  engineering  as  follows: 
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Systems  engineering  is  an  interdisciplinary  approach  and  means  to  enable 
the  realization!  of  succesful  systems.  It  focuses  on  defining  customer 
needs  and  required  functionality  early  in  the  development  cycle, 
documenting  requirements,  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem. 

Furthennore  the  INCOSE  handbook  states  that: 

Systems  engineering  integrates  all  the  disciplines  and  specialty  groups  into 
a  team  effort  fonning  a  structured  development  process  that  proceeds  from 
concept  to  production  to  operation.  Sytems  engineering  considers  both  the 
business  and  the  technical  needs  of  all  customers  with  the  goal  of 
providing  a  quality  product  that  meets  the  users  needs. 

Systems  engineering  is  a  matter  of  applying  fundamental  principles, 
methodologies,  and  is  a  certain  way  of  thinking.  Therefore,  many  different  systems 
engineering  process  models  are  in  use  today,  as  is  shown  in  Figures  15,  16  and  17.  Even 
in  these  different  schemes,  several  common  themes  to  approaching  complex  problems 
can  be  found.  In  particular  the  interdisciplinary  character  of  it  and  also  the  many  specialty 
groups  involved  in  the  systems  engineering  process  requires  a  team  to  form  a  structured 
development  process  that  proceeds  from  concept  to  production  to  operation  (see  Figure 
17).  It  is  important  to  understand  that  there  is  not  a  certain  systems  engineering  process 
that  applies  for  every  project.  Thus,  the  systems  engineering  process  (SEP)  is  a  custom 
tailored  process  of  methodologies  and  tools  which  applies  only  to  a  particular  project. 
Today  knowledge  of  systems  engineering  methodologies  is  crucial  for  all  personnel  in 
military  acquisition  programs,  and  thus  it  is  required  in  the  U.S.  Department  of  Defense 
(DoD)-5000  series. 
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Systems  engineering  needs  business,  technical  and  managerial  knowledge  and 
skills.  A  simple  way  to  explain  the  principle  steps  within  an  SEDP  is  shown  Figure  6 
(Sage,  Armstrong  2000). 


Figure  6.  Systems  engineering  steps  according  to  Sage  and  Armstrong. 


The  United  States  General  Accounting  Office  (GAO  2001)  states  that  systems 
engineering  tools  are  critical  for  identifying  gaps  between  the  developer’s  resources  and 
customer’s  expectations. 

Systems  engineering  is  a  process  that  not  only  translates  customer  wants 
into  specific  capabilities,  such  as  individual  technologies  and 
manufacturing  processes,  but  also  provides  knowledge  that  enables  a 
developer  to  identify  and  resolve  gaps  before  product  development  begins. 

It  is  defined  as  a  logical  sequence  of  activities  that  transforms  a  customer 
want  into  specific  product  characteristics  and  functions  and  ultimately  into 
a  preferred  design.  It  is  not  necessarily  the  use  of  systems  engineering  in 
the  development  of  a  new  product  or  weapon  system,  but  when  it  is  used 
that  distinguishes  it  as  a  best  practice. 
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The  systems  engineering  processes  described  earlier  are  shown  in  Figure  7. 


Figure  7.  SE  process  for  customer  needs  analysis  according  to  the  GAO  report. 


The  V-model  depictured  in  the  DAU  PM  Tool  Kit  (Under  Secretary  of  Defense 
2009)  illustrates  the  systems  engineering  processes  in  relationship  to  the  technical 
management  processes. 


Figure  8.  Systems  engineering  process  in  relation  to  technical  management  processes. 


The  SEP  as  shown  in  Figure  9  (by  Professor  Eugene  Paulo,  not  published) 
considers  all  influences,  such  as  history,  culture,  ethics,  politics,  technology,  and 
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economics,  within  a  program.  It  shows  a  more  general  but  comprehensive  picture  of 
systems  engineering. 
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Figure  9.  SEP  by  Systems  Engineering  Department,  NPS. 

The  DoD  Defense  Acquisition  Guidebook  (Under  Secretary  of  Defense  2011) 
summarizes  systems  engineering  in  military  procurement  as  a  set  of  overarching 
processes  that  a  program  team  applies  to  develop  an  operationally  effective  and  suitable 
system  from  a  stated  capability  need.  The  Guidebook  concludes  that  systems  engineering 
processes  apply  across  the  acquisition  life-cycle  (adapted  to  each  phase)  and  serve  as  a 
mechanism  for  integrating  capability  needs,  design  considerations,  design  constraints, 
and  risk,  as  well  as  limitations  imposed  by  technology,  budget,  and  schedule.  Thus, 
systems  engineering  processes  should  be  applied  during  concept  definition  and  then 
continuously  throughout  the  life-cycle.  Systems  engineering  in  the  U.S.  DoD  acquisitions 
stands  for  the  principal  way  to  achieve  the  best  solution  without  involving  military  and 
political  rules  and  regulations. 
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The  defense  acquisition  guidebook  (Under  Secretary  of  Defense  2011)  states  that: 


Balanced  system  solutions  are  best  achieved  by  applying  established 
systems  engineering  processes  to  the  planning,  development,  and 
sustainment  of  a  system  or  a  system-of-systems  (SoS)  acquisition  in  an 
Integrated  Product  and  Process  Development  (IPPD)  framework.  Systems 
engineering  offers  a  technical  framework  to  enable  sound  decision  making 
relative  to  trade  studies,  system  performance,  risk,  cost,  and  schedule.  The 
successful  instantiation  of  proven,  disciplined  systems  engineering 
processes  results  in  a  total  system  solution  that  is  adaptive  to  changing 
technical,  production,  and  operating  environments  and  to  the  needs  of  the 
use  and  is  balanced  among  the  multiple  requirements,  design 
considerations,  design  constraints,  and  program  budgets. 

The  general  validity  of  systems  engineering  for  a  project  and  its  independence 
from  different  national  regulations  and  rules  makes  it  also  applicable  and  valuable  to  the 
German  procurement  system. 

No  series  comparable  to  the  “DoD  5000”  exists  in  the  Gennan  Bundeswehr  to 
regulate  and  guide  civilian  and  military  personnel  involved  in  procurement  and 
acquisition  programs,  but  by  applying  the  systems  engineering  procedures  these 
personnel  can  lead  a  program  to  success  nonetheless. 
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B.  ANALYSIS  OF  THE  GERMAN  PROCUREMENT  PROCESSES 

The  organizational  structures  of  the  Bundeswehr  provide,  in  general,  the 
possibility  for  the  agencies  to  work  together  more  closely  than  in  the  past.  With  a  new 
interpretation  concerning  the  separation  of  responsibilities  in  procurement  from  the 
military  tasks  given  by  law,  it  is  now  possible  to  concentrate  on  technical  (often  provided 
by  civil  servants)  and  operational  experience  (provided  by  military  personnel)  under  one 
organizational  ceiling,  the  BAAINBw.  The  German  DT&E,  conducted  by  WTDs 
concerned  with  contracted  specifications  and  certification,  is  professional  and  important. 
The  absence  of  OT&E  agencies,  particularly  their  organizational  structures  and  their 
experience,  in  the  German  forces  is  a  disadvantage  in  any  procurement  program  and  its 
management.  Only  an  experienced  OT&E  agency  involved  early  in  a  program  is  able  to 
support  a  PM  concerning  all  operational  matters  and  enable  him/her  to  deliver  a  mature 
and  operationally  useful  product  on  time  and  within  the  cost  schedule.  Consequently, 
because  of  this  lack  of  project  organization  structure  the  PM  has  only  limited  possibilities 
to  fonn  a  powerful  project  team,  called  the  IPT. 

Strategic  planning,  including  monitoring,  analyzing,  and  defining  capability  gaps 
and  needs,  is  now  conducted  by  the  PlABw  under  the  supervision  of  the  MoD,  the  top 
military  and  defense  political  level  of  the  Bundeswehr  and  the  government,  whereas 
procurement  processes  are  more  generally  delegated  by  the  Director  of  the  Federal  Office 
of  Bundeswehr  Equipment,  Information  Technology  and  In-Service  Support  to  the 
BAAINBw. 

The  new  approach  of  allocating  responsibilities  and  power  according  to  the  IPP 
establishes  a  more  direct  and  clearer  way,  and  it  attempts  to  involve  as  few  as  possible 
within  the  process  to  minimize  disturbances  and  to  highlight  the  positions  of 
responsibility.  Additionally,  it  is  recognized  and  acknowledged  that  professional 
expertise  within  the  process  steps  is  crucial  and  always  required.  The  introduction  of 
variable  IPTs  particularly  emphasizes  this  consideration.  Also,  the  strengthening  of  the 
PM’s  responsibilities  and  power  in  decision  making  proves  that  unsuccessful  experiences 
from  the  past  have  been  taken  into  account. 
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The  CPM  and  its  segments  and  processes  are,  in  principle,  like  processes  shown 
in  the  U.S.  DoD  5000,  project  management  literature,  and  systems  engineering 
handbooks.  Working  steps  within  the  CPM  are,  of  course,  tailored  to  Bundeswehr 
organizational  requirements,  but  compared  to  the  U.S.  DoD  5000  or  other  project 
management  publications,  the  CPM  has  a  new  approach  concerning  the  duration  of  a 
program  because  a  program  still  exists  as  a  program  even  when  it  is  handed  over  to  the 
user.  The  PM  and  his  IPT  have  to  care  about  many  issues,  for  example,  improvement, 
obsolescence,  operations  analysis  concerning  maintenance  and  software  maintenance 
improvements  over  the  life  time  of  a  product.  The  user  cares  “only”  about  operational 
wear  and  tear  and  the  maintenance  on  an  operational  level.  This  means  the  program 
actually  ends  when  the  process  of  disposal  and  withdrawal  has  been  finished. 

In  particular  complex  weapon  systems  today  undergo  a  constant  improvement, 
adaption  and  obsolescence  process  to  keep  them  up  to  state-of-the-art  conditions.  For 
example,  an  Apache  AH  64A  helicopter  cannot  be  considered  the  same  as  today’s  AH 
64D  (or  soon  the  E)  version.  Often  before  a  mature  and  deployment-readiness  level  is 
achieved,  the  requirements  for  the  next  update  of  a  system  have  already  been  launched. 
Therefore,  the  program’s  objective  will  never  really  be  achieved.  The  new  Bundeswehr 
approach  took  that  into  account.  On  the  other  hand,  this  approach  is  not  in  accordance 
with  the  aim  that  the  procurement  process  should  be  faster  and  avoid  major  requirement 
changes  during  the  procurement  process.  The  idea  is  to  have  good  performance  if  not  the 
required  perfonnance  in  time  and  within  the  budget  framework.  One  indication  of  this 
aspect  is  the  lack  of  a  change  management  procedure  as  part  of  the  CPM. 

The  fundamental  procurement  and  program  management  processes  follow  today’s 
research  knowledge  and  connect  or  adapt  it  to  the  Bundeswehr  organizational 
requirements.  Neither  of  the  IPP  and  CPM  document  dives  deeper  into  actual  work 
processes  nor  explains  or  detennines  how  the  requested  deliverables  can  be  realized.  This 
thesis  shall  complement  the  described  processes  in  that  matter. 
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IV.  SYSTEMS  ENGINEERING  AND  THE  CPM’S  ANALYSIS 

PHASE:  PART  1 


A.  ANALYSIS  PHASE  PART  1:  FFF  PHASE 

The  CPM  depicted  in  Figure  5  shows  the  schematic  order  of  sequence  of  a 
procurement  program.  The  initial  analysis  phase  shown  is  conducted  by  the  Planungsamt, 
which  is  responsible  for  the  principal  capability  management  in  the  Bundeswehr.  The 
capabilities  management  process  aims  to  recognize  capability  gaps  and  to  derive  and 
define  needs  of  the  forces.  The  Planungsamt  has  oversight  for  the  current  capability 
position  by  continuously  monitoring  and  analyzing  the  current  capabilities  of  the 
Bundeswehr.  When  a  capability  gap  is  identified,  the  need  is  to  derive,  formulate,  analyze 
and  assess  it  in  respect  to  its  significance  in  respect  to  the  overall  capabilities  of  the 
Gennan  anned  forces.  When  a  materiel  solution  is  requested,  a  tasked  IPT  has  to  work 
out  an  FFF.  The  FFF  describes  the  capability  gap  and  the  functional  requirements. 

The  following  information  must  be  included  in  the  FFF  paper: 

•  Designation  of  the  required  capability  (need) 

•  Extrapolation  of  the  capability  from  reference  documents  and  a 
description  of  capability  gap  in  the  system  context  of  the  Bundeswehr 

•  Description  of  the  functional  requirements  and  project  elements 

•  Infonnation  about  time-frame  and  life-cycle  costs 

•  Information  about  amount,  duration  of  usage,  and  future  users  /operators 

•  Financial  requirements  for  analysis  phase 

•  Detennination  if  fundamental  national  interests  are  concerned 

In  addition,  the  following  tasks  are  conducted  within  this  phase. 

•  Market  surveys  and  assessments  of  available  products  and  services 

•  Analysis  and  assessment  of  an  improvement  of  “in  service”-  systems  of 
possible  national  and  international  cooperation  and  the  feasibility  of 
developing  new  products 

•  Show  risks  and  impact  on  procurement  and  operation  of  a  system 

•  Determine  amount  and  life-cycle  costs  and  economic  analysis  (efficiency) 

•  Predict  time  frame  and  financial  funding  for  procurement  and  operation 

•  Assessment  of  effectiveness  of  the  functional  requirements  with  respect  to 
quality  and  quantity 

•  Planning  of  procurement  and  operation  phase 
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The  required  information  and  processes  delivered  in  the  FFF  document  can  be 
found  and  defined  by  applying  systems  engineering  methodologies  and  their  tools. 

B.  APPLYING  SYSTEMS  ENGINEERING 

1.  Needs  Analysis 

In  systems  engineering  the  CPM’s  analysis  phase  is  called  needs  analysis.  The 
most  important  issue  in  this  phase  is  to  identify  and  understand  the  problem  and  then  to 
derive  the  need  correctly.  Usually,  in  an  early  stage  of  the  CPM’s  initial  analysis  phase,  it 
is  very  unlikely  that  a  clear  picture  exists  of  what  exactly  these  scenarios  are  and  what  the 
gap  between  them  may  be.  If  the  early  analysis  process  fails  to  identify  and  to  understand 
the  problem  properly,  the  future  solution  might  not  solve  the  problem  and  cover  the  need. 
The  purpose  of  this  phase  in  systems  engineering  is  to  ensure  that  the  right  need  and  not 
the  “want”  is  captured,  as  well  as  to  agree  on  the  problem  of  where  the  need  is  derived 
from.  A  systems  engineering  approach  requires  a  review  of  the  current  environment  and 
current  system  in  use.  The  purpose  of  this  review  is  to  detennine  the  level  of  the  current 
system’s  requirement  fulfillment  in  respect  to  the  initial  problem  statement  (primitive 
need),  and  through  a  needs  analysis,  to  develop  a  revised  problem  statement  (effective 
need). 


Blanchard  and  Fabrycky  (2011)  describe  the  problem  definition  and  need 
identification  as  follows: 

It  is  important  to  commence  by  first  defining  the  “problem”  and  then 
defining  the  need  for  a  specific  system  capability  that  (hopefully  is 
responsive.  It  is  not  uncommon  to  first  identify  some  “perceived”  need 
which,  in  the  end,  doesn’t  really  solve  the  problem  at  hand.  In  other 
words,  why  is  this  particular  system  capability  needed?  Given  the  problem 
definition,  anew  system  requirement  is  defined  along  with  the  priority  for 
introduction,  the  date  when  the  new  system  capability  is  required  for 
customer  use,  and  an  estimate  of  the  resources  necessary  for  its 
acquisition.  To  ensure  a  good  start,  a  comprehensive  statement  of  the 
problem  should  be  presented  in  specific  qualitative  and  quantitative  terms 
and  in  enough  detail  to  justify  progressing  to  the  next  step.  It  is  essential 
that  the  process  begin  by  defining  a  “real”  problem  and  its  importance. 
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Therefore,  the  first  step  in  the  needs  analysis  is  to  conduct  a  background  research 
in  respect  to  the  Anti-Submarine  Warfare. 

2.  Anti-Submarine  Warfare 

a.  Introduction 

Today  the  world’s  economy  relies  on  the  free  trade  and  transportation  of 
goods.  Accordingly,  Admiral  Gary  Roughhead,  General  James  T.  Conway  and  Admiral 
Thad  W.  Allen  stated  in  2007: 

Because  the  maritime  domain — the  world’s  oceans,  seas,  bays,  estuaries, 
islands,  coastal  areas,  littorals,  and  the  airspace  above  them — supports 
90%  of  the  world’s  trade,  it  carries  the  lifeblood  of  a  global  system  that 
links  every  country  on  earth. 

The  current  German  Defense  Policy  Guidelines  (Gennan  Ministry  of 
Defense  2011)  address  that  concern  as  follows: 

Free  trade  routes  and  a  secure  supply  of  raw  materials  are  crucial  for  the 
future  of  Gennany  and  Europe.  Around  the  globe,  changes  are  taking 
place  in  markets,  channels  of  distribution,  and  the  ways  in  which  natural 
resources  are  developed,  secured  and  accessed.  The  scarcity  of  energy 
sources  and  other  commodities  required  for  high-technology  products  will 
have  implications  for  the  international  community.  Restricted  access  can 
trigger  conflicts.  Disruptions  of  transport  routes  and  the  flow  of  raw 
materials  and  commodities,  e.g.,  by  piracy  or  the  sabotage  of  air  transport, 
pose  a  threat  to  security  and  prosperity.  This  is  why  transport  and  energy 
security  and  related  issues  will  play  an  increasingly  important  role  for  our 
security. 

In  accordance  with  the  economic  importance  of  the  sea  and  maritime 
transportation  of  goods,  nations  established  naval  forces  to  enable  a  free  maritime 
transport  worldwide.  Only  naval  forces  are  able  to  ensure  and  to  protect  the  transport  on 
sea.  This  is  especially  true  for  the  leading  economic  powers,  like  the  U.S.,  China  and 
many  European  countries  (see  Figure  10).  Subsequently,  their  naval  forces  must  have  the 
capability  to  handle  a  significant  challenge,  the  growing  number  of  nations  operating 
submarines.  Only  when  it  is  equipped  with  the  necessary  products  and  knowledge,  can 
the  U.S.  Navy  operate  freely  at  sea  (Admiral  Roughhead,  General  Conway,  Admiral 
Allen,  2007): 
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The  ability  to  operate  freely  at  sea  is  one  of  the  most  important  enablers  of 
joint  and  interagency  operations,  and  sea  control  requires  capabilities  in  all 
aspects  of  the  maritime  domain,  including  space  and  cyberspace.  There  are 
many  challenges  to  our  ability  to  exercise  sea  control,  perhaps  none  as 
significant  as  the  growing  number  of  nations  operating  submarines,  both 
advanced  diesel-electric  and  nuclear  propelled.  We  will  continue  to  hone 
the  tactics,  training  and  technologies  needed  to  neutralize  this  threat. 

The  threat  caused  by  submarines  during  World  War  II  and  some  years 
later  by  the  submarines  of  the  former  UDSSR  during  the  Cold  War  emphasizes  this 
conclusion  in  principle.  This  conclusion  is  true  for  the  German  Navy  as  a  NATO 
member,  too.  The  following  picture  shows  the  known  nations  which  have  operational 
submarines  in  their  forces. 


Figure  10.  Countries  with  submarines.  Green  depicts  countries  with  conventional  armed 
submarines,  orange  depicts  countries  with  ballistic  armed  submarines. 


The  routes  for  the  transport  of  goods  on  sea  are  shown  in  Figure  1 1 
(Martrans,  2011).  Except  the  routes  on  the  Atlantic  Ocean,  between  Europe  and  the  U.S., 
many  main  routes  are  located  close  to  shorelines  and  use  narrow  straits  and  canals. 
Especially  small  submarines  with  diesel  or  air-independent-propulsion  (AIP)  are  able  to 
operate  in  shallow  waters  (brown  waters)  to  disturb  and  even  stop  international  sea  traffic 
at  these  vulnerable  routes.  Therefore,  the  capability  to  protect  worldwide  maritime 
shipping  from  threat  by  submarines  is  crucial  and  a  basic  requirement  for  naval  forces  of 
these  countries.  This  capability  is  known  as  Anti-Submarine-Warfare  (ASW). 
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Figure  1 1 .  Map  of  world  maritime  transportation  routes. 
b.  Definition  of  ASW 

According  to  “Littoral  Undersea  Warfare  in  2025,”  thesis  report  (2005) 
ASW  means  denying  the  enemy  the  “effective”  use  of  its  submarines  and  deterring  an 
enemy  submarine  from  its  mission,  and  if  needed,  destroying  it. 

To  render  an  enemy  submarine  “ineffective”  requires  the  ability  to  detect, 
track,  localize,  and  destroy.  This  goal  is  achievable  through  a  mix  of  naval  platforms  such 
as  aircraft,  surface  ships,  friendly  submarines,  and  the  application  of  operational  tactics 
and  doctrines.  Furthermore  the  paper  states  that  in  the  near  future,  various  unmanned 
vehicles  will  likely  also  join  this  list  of  platforms  to  support  this  warfare. 

3.  ASW  in  the  German  Navy 
a.  Historical  Context 

The  German  Navy  has  a  long  and  well  known  history  with  respect  to 
submarine  warfare.  In  World  War  I  and  II  German  submarines  operated  very 
successfully.  In  particular,  during  the  years  1939  to  1942  German  submarines  operated  in 

the  North  and  South  Atlantic,  in  the  Mediterranean,  the  Baltic  Sea  and  the  North  Sea  to 
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disturb  the  convoys  transporting  resources  and  military  goods  from  the  U.S.  to  their 
European  allies.  From  1943  until  1945  the  use  of  new  ASW  tactics  in  combination  with 
sea  and  air  weapon  systems  led  to  the  massive  loss  of  Gennan  submarines,  and  these 
tactics  disabled  them  from  operating  effectively.  The  German  submarines  were  then  the 
hunted  and  were  no  longer  able  to  threaten  the  allied  sea  transports  seriously  (Wikipedia, 
2013).  However,  having  the  knowledge  and  experience  to  operate  a  submarine  very 
effectively  enabled  the  Bundesmarine  (Federal  German  Navy,  founded  in  1956)  to 
rebuild  and  to  establish  a  new  the  submarine  weapon. 

The  Bundesmarine  was  designed  as  a  NATO  naval  force,  and  their  task 
was  to  blockade  the  sea  routes  into  and  out  of  the  Baltic  Sea,  to  escort  convoys  and  to 
protect  their  routes  from  the  U.S.,  whereby  the  North  Sea  was  the  main  operating  area 
(Sander-Nagashima,  2006).  The  ASW  capabilities  of  the  Bundesmarine  were  constantly 
enhanced  and  included  all  major  weapon  systems  necessary  for  conducting  ASW 
comprehensively  and  effectively.  Interactive  training  and  knowledge,  exchanged  between 
Gennan  and  NATO  submarines,  fonned  the  German  Navy’s  ASW  units  and  personnel  to 
one  of  the  best  in  the  NATO  concerning  operations  in  shallow  waters. 

The  following  naval  weapon  systems  were  used  in  a  well  composed  and 
sufficient  number  to  establish  an  enduring  ASW-mission  together  with  other  NATO 
ASW-assets: 

•  Maritime  Patrol  Aircraft  (MPA) 

•  ASW  helicopters  (an  organic  part  of  ASW  frigates) 

•  ASW  frigates 

•  submarines 

•  minesweepers  (also  used  for  placing  sea-mines) 

Since  the  reunification  of  Gennany  and  the  end  of  the  Cold  War  the 
strategic  concept  and  extent  of  the  Bundeswehr  has  changed  several  times.  The  current 
valid  Gennan  Defense  Guidelines  (2011)  define  the  role  of  the  Gennan  armed  forces  in 
accordance  with  current  and  likely  future  threats.  The  capabilities  will  be  adapted  in 
respect  to  the  new  missions  and  tasks  (Gennan  Ministry  of  Defence,  2011). 

The  capabilities  of  the  Bundeswehr  are  derived  from  its  mission  and  tasks, 
with  the  national  level  of  ambition  acting  as  a  guideline.  A  prioritization 
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within  the  capability  spectrum  is  based  on  the  likelihood  of  risks  and 
threats  that  require  a  military  contribution,  on  the  time  needed  to  provide 
these  capabilities,  on  an  assessment  of  national  interests,  and  on  the 
availability  of  funds. 

That  means  that  not  all  necessary  capabilities  will  be  available  in  fonn  of 
weapon  systems. 

The  variation  and  number  of  needed  capabilities  underlie  the  likelihood  of 
risk,  threat  and  funding.  ASW  missions  currently  are  no  longer  considered  as  primary 
capabilities  of  the  German  Navy,  but  the  capabilities  and  the  knowledge  will  be 
preserved.  The  principal  capabilities  to  conduct  ASW  missions  are  still  available. 
Accordingly,  the  German  Navy’s  present  ASW  assets  are  MPA,  ASW  helicopters, 
submarines  and  the  F-123  class  frigate  (4  units).  Except  for  the  helicopters,  however,  the 
number  of  ASW  systems  has  been  reduced  significantly  and  does  not  allow  for  well 
composed,  interactive  and  enduring  ASW  missions  due  to  the  reduced  numbers. 

4.  Overview  of  Current  German  Navy  ASW  Assets 

a.  Subsurface  ASW  assets 

Four  type  212  submarines  (batch  1)  are  already  in  service  (Figure  12),  and 
two  more  (batch  2)  have  been  ordered  and  will  enter  service  in  2015.  The  submarines  are 
equipped  with  AIP  technology  for  long-distance  submerged  passaging  to  the  area  of 
operation  and  long-tenn  submerged  operations  in  the  area  of  operation.  The  main  tasks 
are  attack  and  surveillance  operations.  The  submarines  have  six  533mm  tubes  for 
DM2A4  torpedoes  (Naval-technology,  2013). 


Figure  12.  German  Navy  U  2 12  Class  submarine. 
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b.  Surface  AS  W  assets 

The  four  frigates  of  the  F123  “Brandenburg”  class  (Figure  13)  were 
designed  and  built  for  ASW  operations,  but  this  type  is  also  capable  of  contributing  to 
anti-air  defense  and  enables  the  tactical  command  of  group  forces  and  surface  operations. 
In  respect  to  ASW  operations  the  F123  type  is  equipped  with  a  sonar  type  DSQS-23BZ, 
Mk  46  (in  the  future,  MU  90)  torpedoes,  and  two  “Sea  Lynx”  Mk  88A  helicopters  (F123, 
2013). 


Figure  13.  Frigate  “Brandenburg”  (F  215)  F123-class. 


The  primary  role  and  weaponry  of  the  three  frigates  of  the  FI 24  “Sachsen” 
class  (Figure  14)  is  Anti-Air  warfare  (AAW),  but  this  type  is  also  capable  of  conducting 
ASW  tasks  because  it  is  equipped  with  a  sonar  type  DSQS-24B,  Mk  46  (in  future,  MU 
90)  torpedoes,  and  two  “Sea  Lynx”  Mk  88A  helicopters  (F124,  2013). 


Figure  14.  Frigate  “Sachsen”  (F  219)  F124  class. 
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Other  German  Navy  ships  in  service,  such  as  the  EGV702  “Berlin”  class 
supply  ships  and  the  K130  “Braunschweig”  class  corvettes,  and  ships  already  in 
acquisition,  such  as  the  new  F125  “Baden-Wurttemberg”  class  frigates,  are  not  designed 
and  equipped  for  ASW  missions,  but  they  do  have  a  landing  deck  and  a  hangar  capacity 
for  two  helicopters.  In  contrast,  the  five  K130  corvettes  have  a  helicopter  landing  deck, 
but  they  can  only  accommodate  small  unmanned  aerial  vehicles  (UAVs)  due  to  limited 
hangar  size.  The  planned  MKZ  180-type  corvette  will  not  be  designed  for  ASW  missions 
primarily,  but  could  be  equipped  with  ASW  technology  by  exchanging  modules.  These 
vessels  will  have  a  flight  deck  and  hangar  for  only  one  helicopter. 

c.  A  erial  AS  W  assets 

The  “Sea  Lynx“  Mk  88  A  helicopter  (Figure  15)  is  embarked  on  the 
frigates  FI 23  and  FI 24  class  and  is  the  mainstay  ASW  system  in  the  German  Navy  and  is 
the  extended  ASW  sensor-end  weapons  of  the  ships.  Accordingly,  the  helicopter’s 
sensors  and  weapons  have  been  tailored  to  its  ASW  task.  It  is  equipped  with  radar,  an 
FFIR  turret,  an  AQS-18(V)-5  dipping  sonar  system  for  active  and  passive  detection,  and 
two  Mk  46  (in  future,  MU90)  torpedoes  (Deutsche  Marine,  2013a).  Twenty  two  of  these 
helicopters  are  currently  in  service  but  only  12  ASW  kits  (dipping  sonar)  were  purchased, 
and  even  fewer  are  available.  Usually  two  “Sea  Fynx”  helicopters  are  embarked  on  a 
frigate,  whereby  due  to  endurance  and  weight  limitations  one  helicopter  is  usually 
equipped  with  a  dipping  sonar  (called  Dipper),  and  the  other  carries  the  torpedoes  (called 
pony)  only. 


Figure  15.  German  Navy  “Sea  Fynx“  Mk  88A. 
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As  a  replacement  for  the  22  aging  Sea  Lynx  “Mk  88A  and  21  “Sea  King 
Mk  41  (which  have  no  ASW  capabilities,  and  thus  are  not  described  here)  helicopter 
fleet,  the  German  Navy  plans  to  procure  currently  one  type  only.  In  all,  18  NHI  MH-90 
helicopters  (Figure  16)  will  replace  the  Sea  Lynx  and  Sea  King  types  and  take  over  their 
duties.  This  new  helicopter  needs  to  be  a  multi-mission  helicopter  to  fulfill  the 
requirements  and  capabilities  derived  from  both  of  the  aging  helicopter  types. 


Figure  16.  Netherland  NFFI  (equivalent  to  the  German  MH-90). 

The  P-3C  “Orion”  (Figure  17)  is  a  maritime  patrol  aircraft  (MPA).  In  2006 
eight  used  aircraft  of  this  type  were  purchased  from  the  Netherland’ s  Navy.  This 
aircraft’s  primary  mission  is  ASW  and  anti-  surface  warfare  (SuW),  but  it  is  also  capable 
for  tactical  command  and  surveillance  missions. 

The  P-3C  is  equipped  with  radar,  an  MX  20  FLIR  system,  a  MAD-sensor 
and  a  sonobuoys  dispenser.  This  MPA  can  deploy  Mk  46  (in  future,  MU90)  torpedoes, 
water-bombs  and  sea-mines  (Deutsche  Marine,  2013b). 
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5.  Analyzing  the  Threat  Caused  by  Submarines 

Conducting  a  threat  analysis  is  a  crucial  step  within  the  needs  analysis.  Only  when 
the  threat  analysis  is  comprehensively  and  thoroughly  conducted  can  that  threat  be  set 
and  compared  to  the  political,  military,  economic  terms  and  conditions.  Much  research 
analysis  has  been  written  and  published  concerning  the  threat  caused  by  submarines. 
Conducting  a  comprehensive  threat  analysis  would  be  beyond  the  scope  of  this  thesis 
because  it  could  easily  extend  to  a  thesis  itself.  Therefore,  some  of  the  published  sources 
which  address  the  submarine  threat  have  been  used  as  reference  in  this  thesis. 
Accordingly,  this  thesis  does  not  conduct  a  comprehensive  submarine  threat  analysis. 
Rather,  it  gathers  the  already  known  results  and  summarizes  this  infonnation. 

As  the  current  German  Defense  Policy  Guidelines  indicate,  free  trade  on  the  sea  is 
crucial  to  Gennany  and  Europe.  The  threat  caused  by  submarines  in  respect  to  the 
freedom  of  free  trade  and  transport  of  goods  on  sea  was  proved  barbarously  in  the  past  by 
the  German  Navy  itself  in  two  world  wars.  Accordingly,  Jane’s  states,  “The  protection  of 
sea  lines  against  underwater  attack  is  vital  for  the  safe  carriage  of  imports  and  exports 
(food  and  materials  and,  during  hostilities,  reinforcements  to  support  the  war  effort),  as 
was  evidenced  during  the  First  and  Second  World  Wars  (Watts,  2005). 

Table  1  underlines  the  vulnerability  of  free  trade  and  transport  of  oil.  In  particular 
the  Strait  of  Hormuz  shows  the  vulnerability  due  to  its  significance  in  respect  to  the 
amount  of  oil  flow  per  day  through  key  world  transit  points  and  its  proximity  to  Iran. 
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Geographic 

Transit  Point 

Oil  Flow 

(million  barrels,  day) 

Primary  Oil  Destination 

Significance  of  Oil 
Transit  Point 

Bab  el  Mandeb 

3.3 

Europe.  United  States.  & 
Asia. 

Closure  would  raise 
transit  time  and 
shipping  costs. 

Bosporous 

1.4 

Western  and  Southern 
Europe. 

Difficult  to  navigate 

Panama  Canal 

0.6 

Atlantic  &  Pacific 

Transfer  Point 

Closure  would  impact 
shipping  costs  and 
transit  tune. 

Strait  of  Hormuz 

14.0 

United  States  &  Western 
Europe 

Closure  would  raise 
shipping  costs  if 
alternative  routes 
were  available 

Strait  of  Malacca 

8.2 

South  Korea.  Japan.  China 
&  Pacific  Run  Nations 

Closure  would  raise 
shipping  costs. 

Suez  Canal 

3.1 

Europe  &  the  United 

States 

Alternative  route  is 
around  south  tip  of 
Africa. 

Table  1 .  Oil  flow  through  significant  world  transit  points.  From  Energy  Infonnation 

Administration. 


Jane’s  counted  in  the  year  2004  that  455  submarines  were  in  use  in  44  countries. 
The  proliferation  of  mostly  conventional  (diesel-electric  and  Air  Independent  Propulsion 
powered)  submarines,  called  SSKs,  enables  countries,  such  as  Iran  and  North  Korea, 
which  are  currently  considered  as  potential  threats,  to  disturb  or  even  interrupt  free  trade 
on  the  sea  and  to  exert  tremendous  influence  on  the  world  safety  and  economy. 

Jane’s  asserts  that  modern  submarines  are  the  most  powerful  weapons  in  today’s 
navies  and  that  they  provide  considerable  fighting  potential.  Increasing  speeds  and  fitting 
of  Air  Independent  Propulsion  (AIP)  systems  in  SSKs  enhances  their  capability.  Modern 
submarines,  in  particular  SSKs,  are  also  extremely  quiet,  and  many  newly  built  boats  use 
acoustic  cladding  to  further  reduce  their  signature.  Jane’s  summarizes  that  the  high 
underwater  speed,  extended  cruising  range,  powerful  weapons  (like  modern  torpedoes 
and  also  submerged  launchable  cruise  missiles,  and  anti-aircraft  missiles)  and  acoustic 
discretion  enable  the  submarine  to  take  maximum  advantage  of  the  underwater 
environment,  and  therefore,  the  submarine  is,  and  will  remain,  a  viable  and  extremely 
potent  weapon  system.  It  will  be  available  for  use  in  an  ever  increasing  number  of  roles. 
Jane’s  conclude  that  the  potential  submarine  threat  is  still  alive  and  real  and  is  becoming 
ever  more  elusive  for  the  hunter  to  detect.  Secondly,  the  threat  to  the  pursuer  from  these 
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submarines  is  becoming  severe  as  submarines  deploy  a  wider  range  of  more  sophisticated 
weaponry  and  counter-measures.  LCDR  Jorgensen  (U.S.  Navy)  concluded  in  his  thesis 
about  P-3C  capabilities  in  ASW  missions  as  follows  (Jorgensen,  2002). 

The  submarine  has  a  wide  variety  of  weapons  available  to  use  against 
surface  and  air  platforms.  This  wide  assortment  of  weaponry  makes  the 
submarine  an  excellent  platform  for  a  navy  to  influence  events  in  a  region 
by  using  torpedoes,  mines,  and  cruise  missiles  offensively.  Also,  the 
addition  of  AAW  missiles  allows  a  submarine  to  defend  itself  close  in 
from  ASW  aircraft.  The  ability  of  a  nuclear  submarine  to  remain 
submerged  for  long  periods  of  time  remains  a  great  challenge  to  ASW 
aircraft.  Meanwhile,  changes  in  technology  have  made  diesel  submarines 
extremely  more  challenging  for  ASW  aircraft  to  prosecute. 

The  last  time  submarines  played  a  major  role  in  a  war  was  during  the  Falklands 
War  between  Argentina  and  Britain  in  1982.  Commander  Karl  A.  Rader  (1994) 
researched  the  Falklands  War  concerning  the  submarine  activities.  Only  some  submarines 
on  both  sides  caused  the  fleets  to  change  their  strategy  significantly  or  required  major 
efforts  to  keep  their  fleet  safe  from  underwater  attacks.  A  successful  torpedo  attack  by  the 
British  SSN  submarine  “HMS  Conqueror”  on  the  Argentine’s  Navy  cruiser  “Belgrano” 
resulted  in  the  loss  of  the  cruiser  and  hundreds  of  dead  sailors.  Yet  the  British  fleet  also 
feared  an  attack  by  the  Argentine  submarines.  Accordingly,  the  British  engaged  over  20 
helicopters  and  10  ships  just  to  drive  off  the  “Sun  Luis.”  Only  some  defects  of  the 
torpedoes  and  the  submarine  spared  the  British  from  the  loss  of  ships.  If  these  attacks 
were  successful  then  most  likely  the  British  efforts  to  free  the  Falklands  could  have 
failed,  due  to  the  submarine  threat  only. 

Rader  (1994)  summarized  that: 

The  Argentines  lost  local  sea  control  due  to  shortcomings  in  hardware. 

Their  plan  to  defeat  the  British  fleet,  a  combined  strike  by  carrier  aircraft, 
surface  ships,  and  submarines,  was  sound.  Their  shortcomings  in  ASW 
hardware  left  them  vulnerable  to  British  submarines.  This  vulnerability 
had  profound  physical  and  moral  effects  on  the  Argentine  Navy's 
operational  perfonnance.  The  Royal  Navy's  successful  power  projection 
operation  also  suffered  from  hardware  shortages.  Land  and  sea  based 
maritime  patrol  aircraft,  and  airborne  early  warning  aircraft,  were  unable 
to  reach  the  AO.  They  accepted  considerable  risk,  counting  on  their 
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perceived  superior  skill  and  the  added  advantage  of  operating  SSN’s.  The 

British  ASW  effort  against  a  single  diesel  submarine  was  a  draw — the 

submarine  retired  safely  without  sinking  any  British  ships. 

Summarizing  the  knowledge  gained  from  the  referenced  sources  enables  one  to 
derive  the  major  threats  caused  by  submarines: 

•  Threat  to  the  civil  economy  by  disturbing/stopping  sea  transport  (free 
trade) 

•  Threat  to  military  operations  on  land  and  sea  by  disturbing  the  military  sea 
supply  chain 

•  Threat  to  military  sea  operations  by  denying  a  ship  or  fleet  entry/stay  in 
the  area  of  operation  (AO) 

•  Threat  to  military  operations  on  land  by  land-target  attack  capabilities 
(conventional  or  nuclear  missiles) 

•  Threat  to  military  sea  and  land  operations  by  supporting  covered  special 
operation  forces  (SOF)  operations 

•  Threat  to  aerial  ASW  operations  due  to  SAM  capabilities 

All  these  threats  have  implications  on  a  strategic  level.  It  is  clear  that  many  more 
ships  and  aerial  assets  are  required  to  achieve  the  same  threat  level  of  the  submarine,  and 
these  forces  are  subject  to  much  greater  risks  than  a  submarine.  These  factors  make  the 
submarine  a  very  desirable,  efficient  and  effective  weapon  with  strategic  value  for  a 
country. 

6.  Analyzing  the  Current  and  Future  (Planned)  ASW  Capabilities  of  the 
German  Navy  in  Respect  to  its  ASW  Assets 

The  German  navy’s  war  fighting  capabilities  during  the  cold  war  were  mainly 
optimized  for  ASW.  The  navy  had  specialized  ASW  frigates,  submarines,  mine  warfare 
(MW/MCM)  units  and  ASW  specialized  helicopters.  This  specialization  was  reasoned  in 
the  threat  caused  by  the  Soviet  submarine  threat,  and  because  Germany’s  navy  was 
tasked  to  protect  NATO’s  supply  routes  and  vessels  to  the  European  war  theater  in  case 
of  war. 


After  the  end  of  the  Cold  War,  Gennany  was  facing  asymmetric  terrorist 

activities,  wars  caused  by  the  disintegration  of  states,  such  as  the  former  Yugoslavia,  and 

by  piracy.  The  threat  of  submarines  disappeared  from  the  strategic  picture  of  politics  and 

the  military.  Since  the  end  of  the  Cold  War,  the  ships  with  ASW  capabilities  were 

withdrawn  and  not  replaced  in  the  same  numbers.  Most  mine  warfare  and  mine  counter 
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measure  (MW,  MCM)  vessels  were  withdrawn  without  any  replacement.  Others  were 
reengineered  for  other  tasks.  The  new  F125  frigates  and  K130  corvettes  have  no  ASW 
capabilities  at  all  and  a  future  planned  corvette  (MZK  180)  will  get  some  ASW 
capabilities  from  ASW  modules  only,  but  it  is  not  purely  designed  for  ASW.  The  Gennan 
Navy  already  realized  that  due  to  its  size  the  MH90  does  not  fit  into  the  hangars  of  the 
only  remaining  ASW  frigates,  the  FI 23,  thus  these  ships  will  see  no  embarked  flight 
operations  with  MH90’s.  Concerning  F124  class  frigates,  a  navy  internal  study  stated  that 
only  a  significant  redesign  of  its  hangars  enables  these  frigates  to  embark  and  service  at 
least  one,  maybe  two  MH90’s,  as  far  as  it  is  technically  feasible  and  affordable.  The  FI 24 
frigates  may  lose  their  helicopters  as  the  main  ASW  sensor  and  weapons  when  the  “Sea 
Lynx”  is  decommissioned  in  the  next  few  years. 

The  new  MH90  helicopter  is  far  more  capable  in  all  mission  areas,  particularly  in 
ASW  missions.  MH90  variants  have  already  proved  capable  of  enduring  approximately 
four  hours  of  flight,  including  simultaneously  carrying  a  dipping-sonar,  sonar  buoys,  two 
ASW  operator  consoles,  a  data-link  system  and  at  least  one  torpedo.  In  contrast,  the  in- 
service  “Sea  Lynx”  cannot  deploy  sonar  buoys  at  all,  has  no  data-link  capability  and  can 
perfonn  only  two  hours  of  flight  even  when  carrying  no  torpedoes,  which  means  it  must 
operate  in  parallel  with  another  torpedo  carrying  “Sea  Lynx.”  In  direct  comparison  one 
MH90  doubles  almost  the  ASW  capabilities  of  two  current  “Sea  Lynx”  helicopters 
through  more  modem  and  sophisticated  technical  equipment  and  better  flight 
perfonnance.  The  trade-off  concerning  the  MH90  is  that  due  to  its  logistic  footprint  and 
size  this  helicopter  type  cannot  be  embarked  on  small  ships  or  on  the  F123/F124  frigates 
which  have  limited  hangar  size.  Controversies  concerning  that  issue  are  already  going  on 
in  the  German  Navy.  Some  leaders  prefer  a  second,  smaller  ASW  helicopter  like  the 
newly  developed  Augusta-Westland  “Wildcat”  AW  159  (the  successor  of  the  “Sea 
Lynx”);  others  prefer  a  one-helicopter  solution,  like  the  multi-mission  MH90 

The  P-3C  “Orion”  was  purchased,  and  is  meanwhile  operational,  only  in  a  small 
number  of  eight  as  the  successor  for  twenty  Breguet-Atlantic  1  MPAs.  The  P-3C  is  still  a 
capable  ASW  asset  and  able  to  conduct  up  to  14-hour  missions,  but  due  to  its  low 
numbers  only  two  or  three  units  can  be  deployed  at  once.  The  remaining  aircraft  are 
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needed  for  training  or  are  in  maintenance.  It  is  nearly  impossible  with  only  eight 
airframes  to  deploy,  to  maintain  eight  aircraft,  and  train  the  crews  properly  in  all  possible 
mission  areas  of  the  aircraft,  especially  in  the  very  challenging  ASW  missions.  Today, 
the  aircraft  is  mainly  used  for  ISR  and  ASuW  missions. 

7.  Summary 

On  the  one  hand  the  German  Navy  will  keep  up  all  capabilities  and  knowledge,  as 
it  becomes  even  more  flexible  for  current  and  future  threats  like  piracy,  but  on  the  other 
hand  it  has  reduced  personnel,  vessels  and  aerial  assets  due  to  financial  constraints  and 
limited  funding.  There  are  ASW  ships,  which  cannot  accommodate  the  MH90  ASW 
helicopter,  and  that  will  cause  the  loss  of  their  main  ASW  sensor  and  weapon.  On  the 
other  hand  ships  without  any  ASW  capabilities,  like  the  FI 25,  can  accommodate  ASW 
helicopters.  This  dilemma  is  still  unsolved  by  naval  leaders.  No  decisions  have  been 
made  yet  as  to  what  the  future  ASW  capabilities  will  look  like  in  the  German  Navy. 

8.  Conclusion 

An  ASW  ship  and  helicopter  fonn  an  organic  team.  A  typical  ASW  mission  needs 
all  available  assets  to  work  together  closely  and  in  a  well-orchestrated  manner  to  detect  or 
at  least  to  deny  a  submarine  access  to  a  certain  mission  area.  An  ASW  ship  without  its 
helicopter-based  main  sensor  and  weapon  cannot  act  effectively  in  ASW  missions.  It  is 
dependent  on  other  aerial  ASW  assets  from  other  ships  or  land  bases. 

To  emphasize  that,  U.S.  Admiral  Morgan  (1998)  delineates  “three  fundamental 
truths  about  ASW”  that  are  worth  mentioning: 

•  ASW  is  critically  important  to  our  strategy  of  sea  control,  power 

projection,  and  direct  support  to  land  campaigns. 

•  ASW  is  a  team  sport,  requiring  a  complex  mosaic  of  diverse  capabilities  in 
a  highly  variable  physical  environment.  No  single  ASW  platfonn,  system, 
or  weapon  will  work  all  the  time.  We  will  need  a  spectrum  of  undersea, 
surface,  airborne  and  space  based  systems  to  ensure  that  we 
maintain. .  .full  dimensional  protection. 

•  ASW  is  hard.  The  near  shore  regional/littoral  operating  environment  poses 
a  very  challenging  ASW  problem. 
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To  underline  the  need  for  a  close  relationship  between  ship  and  helicopter  during 
the  Falklands  War,  in  his  monograph,  Commander  Karl  A.  Rader  (1994)  states: 

“An  aspect  of  ASW  that  has  not  changed  since  World  War  II  is  the 
numerical  imbalance  between  submarines  and  the  assets  required  to  find 
and  destroy  them.  The  British  experienced  a  similar  imbalance  in  the 
Falklands  against  a  defending  submarine.  It  took  the  efforts  of  over  20 
helicopters  and  10  ships  to  eventually  drive  off  the  ‘San  Luis’." 

Only  one  SSK  submarine  of  the  Argentine  Navy  caused  a  serious  threat  to  the 

British  expeditionary  fleet.  The  submarine  primarily  attempted  to  disturb  or  destroy  the 

British  AAW  defense  screen  by  attacking  these  ships  to  free  the  way  for  air  attacks.  Due 

to  the  remote  location  of  the  Falklands,  fixed-wing  ASW  assets  were  not  available.  The 

British  expeditionary  fleet  had  to  rely  on  ships  and  helicopters  only  to  protect  the  fleet 

from  the  imminent  submarine  threat. 

Jane’s  (Watts,  2005)  states  that  modem  submarines,  whether  SSN  or  SSK,  pose  a 
formidable  threat,  and  it  takes  a  force  of  considerable  size  and  a  composition  of  assets  to 
carry  out  a  search  to  detect,  localize,  classify,  and  destroy  a  hostile  submarine. 
Furthennore,  Jane’s  presumes  that  it  will  become  even  more  difficult  to  prosecute  ASW 
as  more  advanced  technology  enters  service  aboard  submarines. 

That  is  valid  particularly  for  SSK  with  AIP  systems  which  come  close  to  SSNs  in 
respect  to  some  performance  parameters,  but  SSKs  are  still  smaller  and  quieter  than 
SSNs.  The  ship-borne  need  for  aerial  ASW  assets  is  crucial  and  practical  in  any  navy 
with  ASW  capabilities  today.  These  ship-borne  assets  are  meanwhile  only  represented  by 
ASW  helicopters.  Even  on  U.S.  aircraft  carriers  aerial  ASW  is  conducted  by  helicopters 
only.  Once  more,  Jane’s  summarizes  that  the  greatest  threat  to  a  submarine  is  the 
helicopter,  and  the  helicopter  equipped  with  MAD,  radar,  EW,  sonobuoys,  and  dipping 
sonar  will  force  submarines  to  remain  near  the  seabed,  restricting  to  a  degree  their 
freedom  of  movement.  In  respect  to  the  already  explained  necessity  of  teamwork  between 
ship  and  helicopters  in  ASW  missions,  the  strategic  planning  concerning  the  Gennan 
Navy’s  ASW  capabilities,  numbers,  and  composition  of  the  different  vessels  and  aerial 
assets  seems  not  to  be  consistent.  The  fact  that  decreasing  funding  allows  for  the 
purchase  of  only  18  MH90s  and  even  fewer  ships  complicates  Gennan  naval  efforts  to 
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maintain  their  ASW  capabilities  at  a  level  commensurate  with  the  economic  importance 
of  sea  transport  and  with  NATO’s  expectations.  Due  to  that  shifting  of  ASW  capabilities 
within  the  Gennan  Navy,  the  navy  will  most  likely  only  be  able  to  conduct  ASW 
operations  together  with  other  nations  or  NATO  ASW  assets. 

9.  Deriving  the  Problem  Statement  and  Primitive  Need 

Fixed-wing  assets  are  needed  to  have  fast  and  long  endurance  ASW  aerial 
capabilities  when  conducting  ASW  operations,  but  the  Falklands  War  in  1982  showed 
these  fixed  wing  assets  are  not  always  available  when  they  are  land-based  only.  That 
problem  can  be  caused  by  long  distances  to  the  area  of  operation  (AO)  or  also  by  threats 
caused  by  SAM  and  hostile  aircraft  when  the  AO  is  very  close  to  hostile  shorelines,  such 
as  the  Strait  of  Hormuz  in  the  Arabian  Sea  to  Iran.  Therefore,  as  already  determined, 
ship-borne  ASW  helicopters  are  crucial  to  any  ASW  mission  and  are  a  requirement  for 
every  fleet  to  defend  submarines  with  the  best  probability.  A  coherent  ASW  capability, 
like  ship-helicopter,  will  no  longer  be  available  for  the  Gennan  Navy.  The  composition 
and  design  of  the  ships  cannot  be  changed  easily  and  quickly,  because  it  is  very 
expensive,  time  consuming  and  would  be  politically  unacceptable.  Only  a  change 
concerning  the  aerial  assets  can  fix  this  problem. 

The  problem  statement  can  be  summarized  as  follows: 

The  Gennan  Navy  will  have  a  capability  gap  concerning  the  availability  of 
ASW  helicopters  in  respect  to  the  feasibility  of  embarkations  on  German 
ASW  capable  frigates  and  future  corvette  types  to  participate  on  ASW 
missions  with  an  organic,  well  composed  sensors  and  weaponry. 

The  primitive  need  can  be  detennined  as  follows: 

The  Gennan  Navy  needs  an  organic  aerial  ASW  weapon  system  for  their 
ASW  capable  ships,  which  can  be  embarked  on  all  existing  and  future 
German  Navy  ships,  and  can  operate  complementary  to  other  NATO 
ASW  systems. 
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C.  DEVELOPING  A  CONCEPT 

1.  Introduction 

Defining  the  problem  and  deriving  the  primitive  need,  as  already  done  before, 
helps  the  IPT  during  the  CPM’s  Analysis  Phase  to  realize  the  extent  of  the  problem  and 
to  recognize  the  need  in  principle.  Systems  engineering  is  an  iterative  process,  which 
ensures  that  the  problem  and  the  need  will  be  redefined  when  other  information  sources, 
like  stakeholder  and  constraints,  have  been  analyzed  before  any  procurement 
requirements  will  be  defined  and  written.  That  process  allows  for  an  understanding  of  the 
entire  problem  and  the  refinement  of  the  need  from  a  primitive  need  to  an  effective  need. 
There  is,  of  course,  not  just  one  way  to  accomplish  this.  Many  approaches  exist  and  can 
be  applied.  It  cannot  be  expected  that  the  IPT  applies  systems  engineering  processes  in 
the  depth  and  quality  as  true  systems  engineers  in  a  company  would  do.  This  process 
should  be  considered  a  very  helpful  step  in  discovering  and  realizing  an  accurate  and 
comprehensive  picture  of  the  problem.  As  a  result,  it  allows  for  an  accurate  derivation  of 
need  and  potential  solution  for  that  problem. 

Figure  18  was  developed  by  a  group  of  SE  students.  It  effectively  illustrates  the 
iteration  processes  between  the  infonnation  sources  and  analyses,  particularly  within  the 
concept  development  phase. 
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Figure  18.  SE  process  developed  and  illustrated  by  students  in  NPS  SE  class  in  2012 


In  their  Capstone  Project  (MSSE  Capstone  Project,  2008)  another  group  of 
students  produced  Figure  19,  which  illustrates  the  process  of  transfonning  a  primitive 
needs  statement  into  an  effective  needs  statement. 


Figure  19.  Needs  analysis  process  [MSSE  Capstone  Project]. 


The  next  appropriate  step  is  the  identification  and  analysis  of  stakeholders 


concerned  with  the  German  ASW  problem.  Only  when  the  stakeholders  have  been 
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analyzed  can  the  boundaries  be  defined  more  easily,  too.  INCOSE  (Haskins,  Forsberg, 
Krueger,  2010)  recommends  identifying  users  and  other  stakeholders.  To  understand  their 
needs,  INCOSE  also  recommends  gathering  customers’  (stakeholders’)  inputs  on  needs, 
wants,  constraints,  and  critical  environment.  An  NPS  thesis  technical  report  (Thesis 
report,  NPS-97-06-001,  2005)  concluded  that  by  identifying  the  stakeholders  it  is  easier 
to  find  the  right  persons  to  determine  the  requirements,  scope  and  boundaries  of  the 
problem.  Furthennore,  it  allows  stakeholders  to  be  involved  in  the  entire  process  of 
definition,  development,  and  deployment  of  the  solution. 

The  stakeholder  analysis  has  several  steps  that  should  include: 

•  Identifying  stakeholders 

•  Identifying  stakeholders’  needs 

•  Conducting  interviews  with  stakeholders 

•  Consolidating  information 

The  V-model  from  the  Tool  Kit  (Under  Secretary  of  Defense  (AT&L),  2009) 
depicts  the  systems  engineering  steps  which  should  be  conducted  to  detennine  the  right 
knowledge  and  infonnation  for  the  FFF  document. 
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Figure  20.  Systems  engineering  process-technical  management  processes  in  respect  to  first 

part  of  the  analysis  phase. 


2.  Stakeholders  and  Their  Needs 
a.  Introduction 

A  stakeholder’s  analysis  requires  a  thorough  review  and  analysis  of 
relevant  stakeholders  and  their  requirements  and  needs.  The  analysis  should  follow  a 
careful  review  of  the  problem  to  identify  and  understand  the  root-source  of  the  problem. 
A  thorough  understanding  of  the  problem  and  a  comprehensive  statement  of  the  problem 
would  have  already  been  presented  to  clarify  a  stakeholder’s  primitive  needs.  Combined 
with  this  statement  later,  conducting  a  stakeholder  analysis  makes  it  possible  to 
distinguish  “needs”  from  “wants”  (Blanchard,  Fabrycky,  2011). 
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The  ISO/IEC  15288  (2008)  explains  the  purpose  for  a  stakeholder 
requirement  definition  process  as  follows: 

The  purpose  of  the  Stakeholder  Requirements  Definition  Process  is  to 
define  the  requirements  for  a  system  that  can  provide  the  services  needed 
by  users  and  other  stakeholders  in  a  defined  environment.  It  identifies 
stakeholders,  or  stakeholder  classes,  involved  with  the  system  throughout 
its  life-cycle,  and  their  needs,  expectations,  and  desires.  It  analyzes  and 
transforms  these  into  a  common  set  of  stakeholder  requirements  that 
express  the  intended  interaction  the  system  will  have  with  its  operational 
environment  and  that  are  the  reference  against  which  each  resulting 
operational  service  is  validated. 

INCOSE  (Haskins,  Forsberg,  Krueger,  2010)  describes  this 
comprehensive  process  as  the  stakeholder  requirement  definition  process  in  which  a 
stakeholder  is  an  individual  or  organization  with  a  legitimate  interest  in  the  system. 
Therefore,  typical  stakeholders  include  users,  operators,  organizations,  decision  makers, 
parties  to  an  agreement,  regulatory  bodies,  development,  agencies,  support  organizations, 
and  society-at-large.  Furthennore,  INCOSE  states  that  the  stakeholder  requirements  are 
an  essential  factor  in  defining  or  clarifying  the  scope  of  a  project.  During  the  stakeholder 
requirements  definition  process  (Figure  20),  it  is  less  important  to  be  concerned  about 
laws,  regulations,  directives,  standards  (Controls).  This  can  be  detennined  in  a  later  step 
during  the  boundaries  definition  process.  In  this  case,  the  concern  should  be  focused  yet 
on  “Inputs”  and  “Enablers”  on  a  basic  level.  Some  requirements  of  certain  stakeholders 
are  usually  more  important  than  others. 
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Figure  2 1 .  Context  diagram  of  Stakeholder  Requirements  Definition  Process.  From 

INCOSE. 


Accordingly,  a  stakeholder  analysis  should  present  the  stakeholder  with 
the  most  important  requirements.  Stakeholders  can  be  categorized  based  on  anticipated 
interaction  with  the  system. 

•  User/Direct  Contact  (those  stakeholders  who  directly  interact  with 
a  system) 

•  Adjacent  Systems  (those  stakeholders  who  operate  adjacent 
systems  or  equipment  that  is  anticipated  to  interact  with  the 
“needed”  system) 

•  Requirements/decision  makers  (those  stakeholders  who  possess 
decision  making  authority  over  a  procurement  program) 

•  Sponsors  (those  stakeholders  who  have  to  pay  for  the  need 

•  Acquisition/decision  makers  (those  stakeholders  who  exercise 
decision  making  authority  over  the  needed  systems  life-cycle) 

The  top-level  stakeholders  in  a  procurement  process  can  be  allocated 
according  to  categorization  (Table  2).  The  stakeholder  in  each  category  can  be  broken 
down  to  lower  levels  to  gain  a  more  detailed  stakeholder  analysis,  but  that  would  exceed 
the  scope  of  this  thesis. 
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User/Direct  Contact 

System  operators;  system  logistic  personnel;  Gennan  forces 

generally,  foreign  military  forces  (NATO,  other  allies) 

Adjacent  Systems 

Support 

Gennan  anned  and  allied  forces,  ASW  community  (other 

assets,  like  ships  helicopters  and  aircraft;  intelligence 

community  (sonar  data);  submarine  community;  naval 

forces  community;  aviation  community,  hostile  forces 

Requirements/Decision 

Maker 

Gennan  government,  Gennan  parliament,  MoD, 

Sponsor 

Taxpayers 

Acquisition/Decision 

Maker 

MoD;  BAAINBw,  Gennan  Navy 

Table  2.  Stakeholder  categories. 


b.  Stakeholder  Needs  Analysis 

System  Operators.  The  system  operators  are  German  military  personnel 
who  operate  the  ASW  asset.  They  will  be  responsible  for  flying,  detection,  identification, 
tracking,  and  engaging  the  threat  with  the  needed  ASW  system.  They  are  the  priority 
stakeholders  since  they  will  be  positioned  “at  the  tip  of  the  spear”  and  are  responsible  for 
operating  the  ASW  system.  Operational  success/failure  of  the  system  depends  utmost  on 
the  system’s  performance  in  conjunction  with  operator’s  perfonnance.  The  system 
operators’  needs  include  adequate  training  for  operating  the  system,  simplicity  in  system 
design  to  ensure  it  is  user-friendly,  availability,  reliability,  and  the  adequate  perfonnance 
to  enable  the  operators  to  fulfill  their  task.  The  operators’  success  or  failure  on  a  mission, 
as  well  as  their  own  lives,  may  depend  on  the  system’s  performance. 

Systems  Logistics.  The  systems  logisticians  are  German  military  system 
maintainers  and  supply  personnel,  civil  employees,  and  civil  contractor  personnel  who 
are  responsible  for  life-cycle  maintenance  of  the  ASW  system.  Their  responsibility  is  to 
ensure  the  weapon  system  is  operational  and  available  when  needed  by  conducting 
routine  and  depot  level  maintenance,  as  well  as  ordering  and  tracking  spare  parts  and 

ammunition.  They  are  also  priority  stakeholders  because  without  needed  availability  the 
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best  systems  have  got  no  value  to  operators.  Needs  for  these  stakeholders  are  the  level 
maintainability,  like  accessibility  and  reparability,  adequate  tools  and  diagnostics,  supply 
support,  appropriate  training  on  system  maintenance,  technical  manuals,  databases,  IT 
systems  capable  of  tracking  maintenance  action  and  supply  support. 

German  and  Allied  ASW  Community.  These  stakeholders  are  personnel 
coming  from  other  ASW  assets,  such  as  ASW  frigates,  helicopters  and  MPA,  from  the 
Gennan  forces,  and  also  from  NATO/allied  forces.  These  personnel  are  secondary 
stakeholders  and  are  also  responsible  for  operating,  flying,  detecting,  identifying, 
tracking,  and  engaging  the  threat  with  their  existing  ASW  system.  They  are  concerned 
that  the  new  system  can  be  integrated  into  existing  systems  and  networks  (that  is,  ships, 
aircraft,  satellite  command  and  control)  in  order  to  provide  a  common  operational 
situational  picture  for  all  participants  and  to  operate  as  a  coherent  ASW  community 
within  the  theater  of  operation. 

Intelligence  Community.  The  intelligence  community  is  composed  of 
military  and  civilian  personnel  who  are  responsible  for  collecting,  analyzing,  and 
communicating  existing  and  potential  threats  to  Germany  and  its  allies.  In  particular, 
information  about  current  and  future  submarine  developments  and  the  impact  on  the 
threat  level  must  be  incorporated  into  the  design  and  development  of  the  new  ASW 
system  accordingly.  Furthermore,  sonar-data  are  needed  to  feed  the  system  to  enable  the 
system  to  detect  and  identify  submarines. 

German  and  Allied  Military  Forces.  The  Gennan  military  forces,  in 
particular  the  Navy,  interact  with  the  system,  and  at  least  all  Gennan  armed  forces’ 
services  are  primary  beneficiaries  of  the  system  and,  therefore,  are  stakeholders.  The 
ASW  system’s  operational  goal  is  to  protect  naval  vessels  from  submarines.  Naval 
vessels  transport  forces  personnel  and  materiel  for  the  Navy,  Army,  and  Air  Force  to  the 
theater  of  operation.  These  vessels  also  protect  Gennan  and  allied  forces  on  land  and  in 
the  air  by  denying  enemy  forces  entry  into  the  operational  theater  from  sea  or  air  (ASuW 
and  AAW  operations).  The  ASW  system  stands  to  gain  or  lose  strategic,  operational,  and 
even  tactical  advantage  of  German  forces  based  on  the  ability  of  the  system  to  deny  and 


eliminate  submarine  threats  on  friendly  forces. 
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The  German  forces  primarily  need  an  adequate  ASW  system  that  is 
capable  of  contributing  significantly  to  an  overall  ASW  effort.  For  example  within  a 
NATO  fleet,  it  is  necessary  to  address  the  perfonnance  and  availability  of  such  systems 
to  protect  German  and  allied  naval  vessels  from  submarine  threats.  These  needs  also 
include  affordability  and  adaptability.  The  German  forces  must  be  able  to  purchase  the 
system  within  current  funding  constraints,  to  tailor  the  system  to  the  environment  and 
facilities,  as  well  as  to  integrate  and  operate  the  system  along  with  other  existing  systems 
of  the  German  anned  forces  and  NATO  forces 

Allied  Governments.  Allied  governments  refer  primarily  to  NATO 
members  and  also  countries  which  may  either  purchase  or  use  this  ASW  system.  These 
stakeholders  benefit  from  lower  cost,  interoperability,  shared  training  and  supply.  NATO 
members  whose  governments  do  not  purchase  the  system  benefit  from  the  capability 
improvement  within  NATO  and  save  money  for  other  assets. 

Enemy  forces.  Hostile  forces  lose  the  advantage  of  their  submarines 
operating  freely  and  disturbing  or  even  to  denying  sea  forces  access  to  their  operational 
area.  They  also  lose  their  ability  to  act  as  freely  as  mission  and  task  demand.  In  short, 
hostile  submarines  lose  their  effectiveness. 

Procurement  Community.  The  acquisition  community  is  composed  of 
civilian  and  military  personnel  from  the  BAAINBw  and  also  the  members  of  the  IPT. 
These  stakeholders  will  need  a  viable  acquisition  strategy  and  plan  that  supports  the 
entire  weapon  system  life-cycle,  an  affordable  system  in  respect  to  funding,  and  an 
available  technology  that  can  be  incorporated  into  the  needed  ASW  system  according  to 
the  schedule,  requirements  and  any  other  constraints.  These  stakeholders  need  funding, 
personnel,  and  information  to  deliver  a  product  that  fulfills  the  requirements  in  order  of 
their  importance  to  all  stakeholders. 

Taxpayers.  Ultimately,  these  stakeholders  “foot  the  bill”  and  have  to  pay 
for  a  new  ASW  system.  Gennany’s  economy  highly  depends  on  exports  and  imports,  so 
the  taxpayers  are  interested  in  open  and  free  trade  of  goods  on  the  sea.  German  citizens 
and  their  economy  primarily  need  an  effective  and  efficient  system  at  an  affordable  cost 
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that  is  capable  of  neutralizing  a  submarine  threat  to  protect  the  economy’s  sea  routes  for  a 
free  trade  of  the  exported  goods  and  imported  commodities. 


German  Parliament.  These  stakeholders  are  composed  of  elected 
officials  who  represent  the  interests  of  Gennany’s  population  and  economy.  On  the  one 
hand  they  have  to  ensure  appropriate  funding  to  establish  forces  to  protect  the  country 
and  national  interests,  but  they  must  do  so  without  exacting  high  taxes.  The  parliament 
also  has  an  interest  in  maintaining  effective  and  efficient  forces,  as  well  as  to  return  some 
of  the  spent  funding  to  German  taxpayers  by  buying  equipment  in  Gennany. 

Therefore,  their  needs  include  life-cycle  affordability  that  protects  the 
Gennan  population,  economy,  military  personnel,  facilities,  and  interests;  while 
neutralizing  threats  to  the  Gennan  and  the  global  economy  (through  free  trade  on  sea).  At 
the  same  time,  they  must  not  lose  focus  on  the  interests  of  the  Gennan  defense  industry. 
The  power  of  controlling  money  and  the  influence  to  the  MOD  make  the  parliament  and 
their  needs,  of  course,  a  primary  stakeholder. 

German  Defense  Industry.  The  defense  industry  is  composed  of  the 
various  companies  that  will  compete  for  a  contract  to  manufacture  a  system  or  at  least 
components  of  a  system.  Their  needs  include  increasing  contract  incentives  to  maximize 
profit,  reducing  production  costs,  as  well  as  reducing  schedule  and  performance  risks  to 
gain  maximum  profit.  These  stakeholders  are  concerned  that  the  system  fits  the  German 
forces’  needs,  but  also  the  needs  of  foreign  forces  to  gain  further  contracts. 

Table  3  summarizes  these  various  stakeholders  and  their  associated  needs. 
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Stakeholder 


(Jain 


^ose 


IN  eeds 


System  operators  *  Successful  defense  of  *  Successful  enemy  attack,  loss 

submarines,  protection  of  own  of  operation  or  own  forces 

forces 


System  logistics  •  Can  “deliver”  availability  as  •  Cannot  “deliver”  requested 

requested,  means  successful  availability  of  the  system  for 

maintenance  service,  save  time  and  operational  use,  need  more 
money  personnel,  higher  efforts,  and 

binding 

ASW  community  •  Increased  overall  ASW  capabilities  •  Decrease  overall  ASW 

(German  &  allies)  capabilities 


Intelligence  community  •  More  sonar  data  gathered  and 
available 


Own  military  forces 

•  Force  protection 

•  Loss  of  vessels 

(German  &  allies) 

•  Freedom  of  operation 

•  Loss  of  freedom  of  operation 

•  Strategic,  operational,  tactical 

friendly  force  activity 

advantage 

•  Strategic,  operational,  tactical 

disadvantage 

Allied  governments 

•  Can  fill  own  gaps 

•  They  do  not  cover  the  gap/need 
within  NATO 

•  Strategic,  operational,  tactical 
advantage 

•  Easy  availability  of  a  new  system 

•  Share  training 

•  Share  supply 

•  Save  money 

•  Need  to  fill  gaps  within  NATO 
themselves 

•  Cannot  share  training  and 
supply 

•  Need  to  develop  a  similar 
system 

Hostile  forces 

•  Freedom  of  operation 
■  Strategic,  operational,  tactical 
advantage 

•  Lose  freedom  of  operation 

*  Strategic,  operational,  tactical 
disadvantage 

Procurement  community 

•  Can  deliver  a  successful  system 

•  Save  funding 

•  Deliver  in  time 

•  Cannot  deliver  a  successful 
system 

•  Need  more  funding 

•  Cannot  deliver  in  time 

Taxpayers 

•  Get  an  equivalent  value  for  tax 
money 

•  Protect  peoples  interests 

•  Protect  und  support  economy 

•  Get  not  an  equivalent  value  for 
tax  money 

•  Cannot  protect  peoples 
interests 

•  Cannot  protect  und  support 
economy 

German  Parliament 

•  Economic  impacts 

•  Protecting  own  and  NATO 
interests 

•  Safe  and  free  trade 

•  Political  implications  (positive  in 
nature  NATO) 

•  Financial  obligation(s) 

•  Political  implications;  potential 
fallout  from  an  ineffective  a 
system 

German  Defense 

Industry 

•  Profit 

•  Intellectual  capital 

■  Improved  reputation 

•  Growth 

•  High  risk  could  result  in 
financial  loss 

•  Possibly  divert  resources  from 
another  ongoing  program 

Table  3.  Stakeholders’  analysis  overview. 


Availability 

Effectiveness 

Survivability 

Interoperability 

Meet  performance  criteria 

Network  capability 

Training 

Design  simplicity 

Maintainability  (design  attributes) 
Logistics/supply  support 
Training 

Integrated  maintenance  Database 

Interoperability 
Network  capability 
Availability 
Effectiveness 

More  capability  to  handle  sonar 
data 

Interoperability 
Network  capability 
Effective  database  management 
system  to  collect,  analyze,  and 
disseminate  threat  information 

Availability 

Effectiveness 

Efficiency 

Survivability 

Interoperability 

Meet  performance  criteria 

Network  capability 

Training 

Design  simplicity 
Maintainability  (design  attributes) 
Logistics./ supply  support 
Integrated  maintenance  database 

Affordability 
Can  be  purchased 


Anti  ASW  capabilities 
Survivability  of  submarines 
More  submarines 

Funding 
Personnel 
Political  support 
Information 
Know-how  exchange 

Effectiveness 
Efficiency 
Equivalent  value 


Affordability 
Trouble  free  program 
Overall  system  effectiveness 
Political  acceptance 


Defined  requirements 
Systems  engineering  plan 
Increased  contract  incentives 
Reduced  cost,  schedule,  and 
performance  risk 
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Table  4  shows  many  stakeholders  exist  and  have  divergent  interests  and 
needs,  but  they  also  share  common  ones  concerning  the  project.  That  overview  supports 
the  next  step,  which  is  to  rank  the  needs  in  respect  to  their  importance  and  influence 
concerning  the  requirements  of  the  ASW  system,  and  then  to  derive  the  requirements 
from  the  needs. 

Many  programs  have  failed  or  were  cancelled  due  to  lack  of  support  by 
the  population  and  government.  The  taxpayer  finances  and  the  government  funds  a 
program  only  as  long  as  the  need  for  a  new  system  is  widely  recognized  in  public  and  the 
political  arena.  That  is  true  in  particular  for  huge  and  expensive  programs;  accordingly, 
the  needs  of  the  taxpayer  and  government  will  be  placed  here  as  one  of  the  most 
important. 

The  needs  of  the  Gennan  anned  forces  are  ranked  second  because  it  is 
more  important  that  a  system  works  effectively  and  efficiently  within  the  composition  of 
all  assets.  Military  systems  usually  work  together  in  a  very  complex  way.  Therefore, 
mission  success  depends  on  the  overall  effectiveness  of  all  systems  combined.  The 
needed  ASW  system  should  be  well  balanced  concerning  the  requirements  to  fit  best  into 
the  existing  and  future  weapon  systems  composition  of  the  Gennan  anned  forces. 
Embedded  within  the  Gennan  Navy  the  system  will  perfonn  as  optimally  as  possible  and 
will,  whenever  possible,  be  available.  The  operator’s  and  logistical  needs  should  be 
considered  next.  Their  needs  are  important  because  they  define  a  lot  of  requirements  and 
influence  the  design  of  the  system.  Adjacent  systems,  such  as  other  ASW  systems  and 
assets,  need  complete  interoperability  to  work  closely  in  a  well-orchestrated  manner  with 
the  new  ASW  system.  The  same  is  valid  for  the  intelligence  community.  The 
procurement  community  is  most  likely  at  the  bottom  of  the  “need”  food  chain,  but 
nevertheless,  they  are  important  to  conduct  a  program  successfully. 
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Table  4  shows  the  ranking  and  the  most  important  common  needs  of  the 
different  stakeholders. 


Stakeholder 

Needs 

Taxpayer, 

Effectiveness 

Government 

Efficiency 

Equivalent  value 

A.  fford  ab  ility 

Trouble  free  program 

Overall  system 
effectiveness 

Political  acceptance 

German  armed 

Availability 

forces 

Effectiveness 

Efficiency 

Survivability 

Interoperability 

Meet  performance 
criteria 

Network  capability 

Training 

Design  simplicity 

Maintainability  (design 
attributes) 

Logistics/supply  support 

Integrated  maintenance 
database 

System  operator 

Availability 

Effectiveness 

Survivability 

Interoperability 

Meet  performance 
criteria 

Network  capability 

Training 

Design  simplicity 

System  Logistics 

Maintainability  (design 
attributes) 

Logistics/supply  support 

Training 

Integrated  maintenance 
Database 

ASW  community 

Interoperability 

(German  &  allies) 

Network  capability 

Availability 

Effectiveness 

Procurement 

Funding 

community 

Personnel 

Political  support 

Information 

Know-how  exchange 

Intelligence 

More  capability  to  handle 

community 

sonar  data 

Interoperability 

Network  capability 

Effective  database 
management  system  to 
collect,  analyze,  and 
disseminate  threat 

information 

Common  Needs 


Effect  i  veness 
Efficiency 
AfFordabi  lity 
Survivabi  1  ity 
Interoperab  i  1  ity 
Meet  performance 
criteria 

Network  capability 
Training 

Design  simplicity 

Maintainability 

Logistics/supply 

Integrated 

maintenance 

database 

Funding 

Personnel 

Effective  database 

management 


Table  4.  Stakeholder  ranking  and  common  needs. 
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At  this  point  it  is  necessary  to  gain  additional  and  detailed  infonnation 
about  the  stakeholders’  needs  and  interests.  So  far,  the  thesis  researched  and  covered  only 
information  from  references,  such  as  books  and  reports.  To  understand  the  true  needs  for 
a  system  the  stakeholder  should  be  asked  in  order  to  get  detailed  infonnation  about  each 
stakeholder’s  needs.  Elicitation  is  one  good  way  to  get  answers,  but  good  questions 
should  be  defined  first.  According  to  Miller  (Class  2012,  NPS),  elicitation  is  not  only  a 
process  of  collection,  but  rather  an  acknowledgment  that  unspoken  needs  and 
considerations  exist. 

Elicitation  is  used  to: 

•  Assess  project  and  solution  feasibility 

•  Identify  organizational  biases 

•  Define  the  user’s  operational  environment 

•  Identify  domain  constraints  limiting  functionality  and  perfonnance 

•  Create  usage  scenarios  to  facilitate  thorough  analysis 

The  clarifying  questions  should  be: 

•  Who  are  the  users  and  how  do  they  intend  to  use  the  product? 

•  What  are  the  reasons  behind  the  system  needed? 

•  Why  is  the  system  being  developed? 

•  What  are  the  user’s  expectations? 

•  How  will  the  user  measure  the  performance  of  the  system? 

•  What  functions  will  the  system  perform,  expressed  in  “user’s 
language?” 

•  Users  can  be  system  operators,  maintainers,  supplier,  and  also 
adjacent  systems  operators,  who  should  be  considered  as  well. 

Naval  Postgraduate  School  students  applied  the  technique  of  elicitation  in 
their  MSSE  Capstone  Project  (NPS-SE-08-002,  2008).  After  identifying  the  major 
stakeholders,  the  students  developed  a  questionnaire  “in  order  to  establish  a  standard  set 
of  interview  elements  for  each  stakeholder.”  The  students  conducted  an  interview  with 
relevant  stakeholders  to  gather  the  needs,  wants  and  desires  of  the  stakeholders.  The 
result  of  their  work  was  presented  in  a  table  with  affinity  categories  derived  for  ASW 
system  “detection”  and  “doctrine”  as  shown  in  Figure  22. 
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Affinity  Results  (sample) 


Affinity  Category 

Original  Needs  Elements 

Goal/Constraint 

Count 

Interpreted  Need 

Count 

Detection 

15 

The  system  should  provide  high  Pd  and  low 
P*a  with  tacocai  significance 

ii 

The  system  should  maxm  ize  search  rate 

3 

The  system  should  maxm  ize  kill  rate 

1 

Doctrine- 

Constraints 

19 

The  system  should  avoid  'orce-on-force 
engagements 

8 

The  system  must  secure  friendly  maneuver 
area:  Sea  Shlei dBase1  Strike 

4 

The  system  should  minimize  die  Fog  or  VV  ar 

i 

The  system  should  optimize  command 
strudure  lo  support  Joint  asw  execuDon 

i 

The  system  needs  to  accommodate  norv 
asw  tasking  or  assets 

i 

The  system  should  oe  offensive  vice 
defensive 

4 

Figure  22.  Affinity  results  (Sample)  of  the  MSSE  Capstone  Project. 


The  students  conducted  a  Pareto  Analysis  presented  in  a  chart  (Figure  22) 
to  prioritize  the  stakeholders’  inputs.  The  students  explain  that  activity  as  follows. 

The  Pareto  chart  is  designed  to  utilize  the  data,  not  perception,  to  separate 
the  few  critical  problems  or  issues  from  a  multitude  of  possible  problems 
or  issues  by  graphically  arranging  the  data  according  to  frequency  of 
occurrence.  The  stakeholder  analysis  generated  207  individual  stakeholder 
inputs  -  clearly  a  multitude  of  data  elements.  The  individual  inputs  were 
subsequently  categorized  into  67  interpreted  results  and  the  occurrences  of 
stakeholder  inputs  assigned  to  each  interpreted  result  were  tallied.  The 
interpreted  need  results  shown  in  Figure  9  were  sorted  and  plotted 
according  20  to  which  results  have  the  highest  occurrences  of  stakeholder 
inputs.  The  interpreted  results  that  contain  the  top  20%  of  the  total  number 
of  stakeholder  inputs  were  identified  as  the  critical  stakeholder  needs. 
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Pareto  Chart 
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Figure  23.  Pareto  chart  [From  MSSE  Capstone  Project,  2008]. 


3.  Boundaries  of  the  Needed  System 
a.  Introduction 

Buede  (2011)  explains  in  his  book  that  a  system  is  a  set  of  entities  that 
interacts  with  the  system  via  the  system's  external  interfaces.  External  systems  can  impact 
the  system,  and  the  system  can  impact  the  external  systems.  Buede  (2011)  also  states  that 
a  system's  inputs  may  flow  from  these  external  systems  or  from  the  context,  but  all  of  the 
system's  outputs  flow  to  these  external  systems.  On  the  other  hand,  the  context  of  a 
system  is  a  set  of  entities  that  can  impact  the  system  but  cannot  be  impacted  by  the 
system  (Figure  24). 
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Context 


\ _ are  impacted  by  “Sy  stem" _  J 

impacts,  but  not  impacted  by.  “System" 

Figure  24.  External  and  Internal  System  Relationship  [Buede,  2011]. 


That  principal  rule  means  that  the  needed  system  will  be  influenced 
(impacted)  from  outside,  and  external  systems  themselves  may  be  impacted  by  the 
needed  system.  The  degree  to  which  these  external  systems  are  impacted  is  determined 
by  the  system’s  boundaries.  Even  from  outside  the  boundaries,  the  system  can  still 
experience  inputs.  These  boundaries  must  be  defined. 

Buede  (2011)  states  concerning  boundaries: 

The  single,  largest  issue  in  defining  a  new  system  is  where  to  draw  the 
system's  boundaries.  Everything  within  the  boundaries  of  the  system  is 
open  to  change,  subject  to  the  requirements,  and  nothing  outside  of  the 
boundaries  can  be  changed,  leading  to  many  of  the  system's  constraint 
requirements.  The  external  systems  diagram  is  the  model  of  the  interaction 
of  the  system  with  other  (external)  systems  in  the  relevant  contexts,  thus 
providing  a  definition  of  the  system's  boundary  in  terms  of  the  system's 
inputs  and  outputs.  Who  is  responsible  for  drawing  these  boundaries?  All 
of  the  stakeholders  have  a  say  in  drawing  these  boundaries. 

It  can  be  summarized  that  a  system  exists  only  within  its  boundaries,  and 
therefore,  the  boundaries  need  to  be  defined.  A  first  step  to  define  the  boundaries  is  to 
define  the  problem,  which  has  been  discussed  already  in  the  previous  chapter.  Another 
source  which  helps  to  define  the  boundaries  is  the  infonnation  received  from  the 
stakeholder  elicitation.  Some  other  sources  include  laws,  regulations,  directives, 
standards,  agreements,  funding  and  many  more.  Additionally,  an  operational  concept  that 
defines  the  operational  boundaries  in  which  a  system  will  work  and  an  “Input-Output 
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Model”  are  appropriate  tools  and  information  sources  for  research  on  a  system’s 
boundaries. 


b.  Identifying  Rules  and  Non-Technical  Constraints 

Rules  and  constraints  are  an  important  part  of  any  system  boundary.  Rules 
are  usually  laws,  regulations,  directives  and  standards.  Research  on  these  rules  is  also 
research  on  stakeholders,  which  should  be  added  into  the  list  of  already  determined 
stakeholders.  The  funding  for  a  new  system  is  the  most  important  constraint.  Funding  for 
a  new  system  requiring  more  than  25  million  Euros  must  be  approved  by  the  parliament. 
That  approval  process  involves  many  different  stakeholders  at  the  top  level  in  the  MoD, 
MoF,  (Bundesministerium  fur  Finanzen,  Federal  Ministry  of  Finance)  and  Defense 
Committee. 

Accordingly,  the  key  players  involved  in  the  funding  issue  should  be 
identified.  Gennany  is  an  important  NATO  member,  and  many  agreements  have  been 
signed  concerning  military  and  procurement  cooperation.  The  needed  system  has  to 
conform  to  the  terms  of  these  agreements;  thus,  the  applicable  NATO  or  bilateral 
agreements  must  be  identified.  Again,  that  would  add  one  more  new  stakeholder  to  the 
list.  Laws  and  regulations  concerning  procurement  and  acquisition  must  be  sifted. 
Additionally,  responsibilities  within  the  MoD  and  also  within  other  governmental 
departments,  such  as  the  Bundesministerium  fiir  Finanzen  (Ministry  of  Finance)  or  the 
Bundesamt  fiir  Sicherheit  in  der  Infonnationstechnik  (Federal  Office  for  Safety  in 
Infonnation  Technology)  must  be  identified,  and  pertinent  laws  must  be  listed.  A  major 
constraint  comes  from  the  Navy  ships  on  which  the  system  shall  be  embarked.  Finally, 
these  examples  show  that  merely  identifying  rules  and  non-technical  constraints  is  a  huge 
effort.  The  IPT  must  perfonn  these  tasks  thoroughly  to  understand  other  stakeholders’ 
interests  and  needs  in  order  to  define  the  system’s  boundaries. 

c.  Identifying  Technical  Constraints 

According  to  the  primitive  need  statement  determined  in  Chapter  I,  the 

needed  system  will  be  an  aerial  system.  For  aerial  systems,  in  particular,  many  technical 

rules  must  be  taken  into  consideration  to  get  an  airworthiness  certification.  Certification 
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is  required  because  these  systems  fly  in  national  and  international  air  spaces,  which  are 
controlled  by  civil  and  military  air  traffic  controllers.  Therefore,  all  aviation  standards 
and  regulations  from  national  and  international  agencies,  such  as  the  U.S.  Federal 
Aviation  Administration  (FAA)  and  the  European  Aviation  Safety  Agency  (EASA), 
related  to  the  needed  system  must  be  determined  and  applied.  Today,  laws  and 
regulations  related  to  environmental  protection  and  safety  are  always  a  concern  in  any 
military  and  civil  project,  and  these  regulations  must  also  be  taken  into  consideration.  A 
system  will  not  get  a  certification  for  use  when  current  minimum  regulations  and 
standards  in  respect  to  that  matter  are  not  implemented. 

Another  crucial  technical  (physical)  constraint  that  must  be  defined  is 
derived  from  the  naval  ships  which  will  accommodate  the  system.  As  already  stated,  it  is 
most  unlikely  that  the  ships  will  undergo  a  major  and  expensive  design  change.  Thus  the 
system  must  fit  into  the  current  physical  environment  (that  is,  the  landing  deck  and 
hangar).  The  needed  system  must  also  interoperate  with  other  technical  equipment  on 
these  vessels.  The  ship  with  the  most  challenging  physical  scale  in  respect  to  size,  weight 
and  interoperability  should  be  selected  to  define  and  derive  these  boundaries,  because  it  is 
usually  much  easier  to  integrate  a  system  in  a  ship  when  enough  physical  reserves  are 
available  for  small  adaptions. 

d.  Operational  Concept 

A  major  effort  that  helps  to  understand  the  “Need”  and  to  define  its 
boundaries  is  to  develop  an  operational  concept  in  respect  to  the  problem.  According  to 
the  ASW  capability  problem,  a  concept  concerning  ASW  in  the  Gennany  Navy  and 
NATO  is  advisable.  The  IPT  will  usually  consist  of  specialists  and  experts  with  some 
experience  in  ASW.  Nevertheless,  the  existing  NATO  and  German  Navy  doctrines  and 
also  the  user  (ASW  community)  can  deliver  an  attuned  operational  concept  based  on  their 
experience  from  conducting  ASW  missions.  Consequently,  the  ASW  experts  (users)  from 
NATO  and,  in  particular,  the  German  Navy  are  in  charge  to  deliver  a  coordinated  and 
applicable  basic  operational  concept  to  enable  the  IPT  to  understand  the  extension  and 
scope  of  ASW  operations.  Researching  and  developing  an  operational  concept  is  out  of 
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the  scope  of  a  procurement-embedded  IPT  due  to  its  limitation  in  knowledge  and 
personnel  strength.  The  IPT  should  be  in  charge  to  gather  information  and  to  transfonn 
these  findings  into  a  “Need”  only.  To  enable  the  IPT  for  that  task,  the  concerned 
stakeholders’  operational  concept  should  contain  viable  information  and  descriptions 
(requirements)  in  respect  to  the  expectations  of  the  system’s  performance  and 
environment. 


The  basic  operational  concept  should  at  least  contain  statements  about: 

•  Mission  definition 

•  Performance  and  physical  parameters 

•  Operational  deployment  or  distribution 

•  Effectiveness  factors 

•  Operational  life-cycle 

•  Utilization  requirements 

•  Environmental  factors 

•  Peer  systems 

e.  Input-Output  Model  and  External  System  Diagram 

The  Input-output  Model  is  a  valuable  tool  to  help  determine  the  scope  of 
the  problem  and  the  boundaries  of  the  “need.”  A  system  consists  of  many  different 
components.  A  system’s  boundary  detennines  whether  a  component  or  subsystem 
belongs  to  a  system.  Systems  are  always  connected  to  their  environment,  and  this 
environment  separates  the  system  from  it.  The  connection  to  the  environment  outside  the 
boundaries  is  established  through  the  inputs  and  outputs  to  and  from  the  system. 
Therefore,  an  Input  and  Output  Model  helps  to  define  the  boundaries  and  to  analyze  the 
inputs  and  outputs.  In  their  MSSE  Capstone  Project  (NPS-SE-08-002,  2008]  the  students 
illustrated  the  controlled  and  uncontrolled  input  into  a  needed  ASW  system  (Figure  25). 
The  parallelism  of  the  capstone  project  in  2008  and  the  “Need”  in  this  thesis  are  close 
enough  that  this  model  is  applicable  in  the  Gennan  case,  too. 
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CONTROLLED  INPUTS 


B> 


•  Sensor  Capabilities 

•  #  Sensors 

•  Sensor  Types 

•  Platform  Capabiities 

•  Weapons  Capabilities 

•  Tactical  Decisions 

•  Communications.'Data 
Processing  Capabilities 

•  Manpower 


UNCONTROLLED 


•  Technology  Limitations 

•  Enemy  System  Capabilities 

•  Enemy  tactics  (Scenarios) 

•  Environment 

•  Location 

•  Weather 

•  Duration 

■  Operator  Limitation 


INTENDED  OUTPUTS 


■  Detection 


e> 


•  Detect 

•  T  rack 

•  Localize 

•  Classify 
•  Deterrence 

•  Diversion 


•  Destroy  (if  req  ) 

•  Communications 

•  Evasion 

•  Tactical  Control 

•  Organic  Tramng  Capability 


UNINTENDED  OUTPUTS 


£> 


•  Counter  Detection 

•  Logistics  Requirements 

•  Technology  Compromise 

•  Friendly  Fire  Loss 

•  Excessive  False  Alarms 

•  Mission  Reassignment 


Figure  25.  Input-Output  Model. 


An  external  system  diagram  delivers  at  least  the  same  results,  but  helps 
with  interfaces  and  more  defined  boundaries  to  illustrate  the  relationships  of  systems 
collaborating  with  the  needed  system.  Figure  26  shows  a  generic  model  of  an  external 
system  diagram  that  puts  the  system  into  its  environment  and  depicts  the  needed  system’s 
relationship  with  other  systems. 


Figure  26.  Generic  context  model. 


63 


The  already  collected  and  known  information  from  backround  analysis, 
stakeholder  needs  and  the  operational  concept  should  make  it  possible  to  explain  the 
relationship  of  collaborating  systems  outside  the  boundaries  as  illustrated  Figure  27. 


The  context  diagram  helps  us  to  understand  and  classify  inputs,  outputs, 
and  relationships  of  the  system  and  helps  to  define  its  boundaries,  but  the  diagram  also 
helps  us  to  detect  failures  in  thinking  and  incorrect  assumptions  made  during  the  previous 
steps. 
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So  far,  it  has  been  assumed  and  stated  that  the  primitive  need  is  about  an 
organic  aerial  ASW  weapon  system  for  ASW-capable  ships.  This  system  can  be 
embarked  on  all  existing  and  future  German  Navy  ships  and  must  interoperate  with  other 
NATO  ASW  systems.  That  might  imply  that  the  system  is  an  independent  system  which 
works  only  closely  with  other  ASW  units,  as  the  current  ASW  helicopters  do.  The 
illustration  of  the  context  diagram  (Figure  28)  incorporates  some  other  valuable 
information  already  available,  as  well  as  some  ideas  about  the  relationships  between  the 
ASW  units  and,  in  particular,  with  the  related  carrying  vessel.  The  diagram  allows  for  the 
assessment  of  the  relationships  and  boundaries  as  a  “system  of  systems.”  In  particular, 
the  network  between  today’s  assets  and  the  already  described  absolute  need  that  ASW 
work  as  “one  unit”  to  be  successful  emphasizes  this  thought.  The  following  context 
diagram  depicts  these  new  thoughts  and  relationships  between  the  ASW  units  and  sets  the 
boundaries  differently. 


Figure  28.  Redefined  “Need”  ASW  system  context  diagram. 
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4. 


Functional  Analysis 


a.  Introduction 

The  purpose  of  a  Functional  Analysis  is  to  determine  at  a  high  level  what 
the  system  must  do  to  fill  a  gap  in  defense.  That  process  happens  through  presenting  the 
analysis  in  an  organized,  articulate,  and  meaningful  way. 

Blanchard  and  Fabrycky  (2011)  describe  this  process  as  follows: 

An  essential  activity  in  early  conceptual  and  preliminary  design  is  the 
development  of  a  functional  description  of  the  system  to  serve  as  a  basis 
for  identification  of  the  resources  necessary  for  the  system  to  accomplish 
its  mission.  A  function  refers  to  a  specific  or  discrete  action  (or  series  of 
actions)  that  is  necessary  to  achieve  a  given  objective,  that  is,  an  operation 
that  the  system  must  perform,  or  a  maintenance  action  that  is  necessary  to 
restore  a  faulty  system  to  operational  use.  Such  actions  may  ultimately  be 
accomplished  through  the  use  of  equipment,  software,  people,  facilities, 
data,  or  various  combinations  thereof.  However,  at  this  point  in  the  life 
cycle,  the  objective  is  to  specify  the  whats  and  not  the  hows;  that  is  what 
needs  to  be  accomplished  versus  how  it  is  to  be  done. 

Functional  decomposition  is  a  fundamental  tool  in  systems  engineering.  It 
identifies  most  broad  functions,  uses  verbs  and  verb  phrases,  decomposes  functions  into 
sub-functions,  and  it  is  about  thinking  functions,  not  components  or  solutions.  The 
functional  decomposition,  in  conjunction  with  different  diagrams  and  charts  provided 
here,  help  to  round  out  our  understanding  of  the  principal  functions  of  the  systems  and  to 
redefine  the  Need  statement  to  an  effective  need.  Furthermore,  functional  decomposition 
is  also  very  useful  for  defining  the  requirements  for  the  system  in  the  next  step  of  the 
systems  engineering  process. 

b.  Hierarchical  Structure  and  Components 

The  hierarchical  structure  helps  to  identify  the  stakeholders  involved 
within  the  boundaries,  to  define  the  systems  involved  concerning  the  “System  of 
Systems,”  and  also  to  identify  involved  stakeholders  outside  the  boundaries  of  a  system 
on  a  high  level.  Additionally,  this  diagram  depicts  the  components  involved  within  the 
hierarchical  structure.  Only  systems  in  current  use  have  been  taken  into  consideration. 

Future  developments  might  extend  the  structure.  The  hierarchical  structure  shown  in 
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Figure  29  is  related  to  the  command  structure  of  military  operations.  Technically,  the 
single  components  are  often  capable  of  communicating  and  transferring  data  between 
each  other,  but  the  different  warfare  operations  and  their  “System  of  Systems,”  for 
example,  ASW,  AAW,  and  ASuW,  need  a  hierarchical  command  structure  to  orchestrate 
the  units  within  the  warfare  operation  to  achieve  the  mission  goal.  Therefore, 
communication  and  data  exchange  between  different  warfare  scenarios  must  be 
conducted  according  to  the  hierarchy  level  as  illustrated  in  Figure  29. 


1.0 


Operational 

Command 

Center 


Figure  29.  Hierarchical  structure  and  components,  including  “System  of  Systems.” 
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c.  Component  Breakdown 

The  component  breakdown  (Figure  30)  illustrates  the  basic  equipment  of 
ASW  vessels  and  aircraft  regarding  their  sensors  and  weapons.  In  respect  to  the  Gennan 
Navy,  the  surface  components  are  the  F123,  F124,  and  MZK  180,  and  the  air  components 
are  the  P-3C  and  the  MK  88 A  and  MFI90  helicopters.  The  ASW  component  breakdown 
applies  also  for  other  NATO  surface  and  air  units. 
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Figure  30.  ASW  component  breakdown. 
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d.  Functional  Flow  Block  Diagram 

Figures  3 1,  32,  and  33  depict  the  functions  of  an  ASW  system  using  a  high 
level  approach,  and  they  also  apply  to  the  Need. 


Functional  Flow  Block  Diagram  Level  1 


Send 


Search 


^  Track 


>  Identify 


^  Process 


^  Confirm 


Clear 


-*© 


^  Encounter 


Assess 


Receive 


Figure  3 1 .  “Need”  ASW  system  functional  flow  block  diagram  Level  1 . 
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Functional  Flow  Block  Diagram  Level  2 
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Figure  32.  “Need”  ASW  system  functional  flow  block  diagram  Level  2. 
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Figure  33.  “Need”  ASW  system  functional  flow  block  diagram  Level  2  (cont.). 


5.  Redefining  the  Need 

The  stakeholder  analysis,  boundaries  definition,  and  functional  analysis  gather  the 
information  and  knowledge  to  understand  all  the  issues  and  concerns  related  to  the  ASW 
more  fully.  The  IPT  should  now  be  in  a  position  to  reanalyze  the  problem  and  redefine 
the  Need  for  the  German  Navy. 

The  early  problem  statement  in  Chapter  II  states  that: 

The  German  Navy  will  have  a  capability  gap  concerning  the  availability  of 
ASW  helicopters  in  respect  to  the  feasibility  of  embarkations  on  German 
ASW-capable  frigates  and  future  corvette  types  to  participate  on  ASW 
missions  with  organic,  well  composed  sensors  and  weaponry. 

The  primitive  need  in  Chapter  II  states  that: 

The  German  Navy  needs  an  organic  aerial  ASW  weapon  system  for  their 
ASW-capable  ships,  which  can  be  embarked  on  all  existing  and  future 
German  Navy  ships  and  which  can  operate  complementarily  to  other 
NATO  ASW  systems. 
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The  problem  statement  redefined  according  to  the  infonnation  and  knowledge 
from  Chapter  III  is  as  follows: 

The  Gennan  Navy’s  ASW-capable  vessels  will  have  a  capability  gap  in 
respect  to  an  organic  and  quickly  deployable  ASW  sensor-system  (sonar) 
to  search  and  engage  submarines  within  distance  of  its  own  surface  units. 

The  redefined  primitive  need,  (effective  need),  which  is  as  follows: 

The  Gennan  Navy’s  ASW-capable  vessels  need  an  organic,  quickly 
deployable,  interoperable,  and  endurable  ASW  system  to  conduct  ASW  at 
some  distance  from  its  own  surface  units  using  the  vessel’s  flight  deck  and 
hangar  for  deployment  and  long-tenn  embarkations. 

6.  Preliminary  Design  Analysis 

a.  Introduction 

Blanchard  &  Fabry cky  (2011)  state  that  having  justified  the  need  for  a 
new  system,  as  was  done  in  the  previous  chapters  of  this  thesis,  it  is  necessary  to  conduct 
some  steps  to  find  the  right  design  for  the  solution: 

•  Identify  various  design  approaches  or  alternatives  that  could  be 
pursued  in  response  to  the  need. 

•  Evaluate  the  feasible  approaches  to  find  the  most  desirable. 

•  Recommend  a  preferred  course  of  action. 

It  is  recommended  (Blanchard,  Fabrycky,  2011)  that  such  a  design 
research  must  address  limiting  factors  like  environmental  ones,  as  well  as  the  projected 
capability  of  each  alternative  to  meet  life-cycle  cost  objectives. 

b.  Basic  Preliminary  Design  Analysis  of  the  ASW  Need 

The  recommendation  mentioned  earlier  applies  also  for  constraints  set  by 
the  customer,  in  this  case  the  German  Navy.  In  particular  the  constraint  that  the  need 
must  mainly  be  adapted  to  the  ships,  and  not  vice  versa,  means  that  expensive  and  time- 
consuming  design  alterations  on  the  ships  is  outside  the  financial  and  policy  boundaries. 
The  Need  shall  be  interoperable  with  the  vesseFs  flight-deck  and  hangar.  Additionally, 
the  system  shall  be  an  easily  deployable  system.  Those  conditions  limit  the  possible 
alternatives  regarding  the  preliminary  design.  Underwater  system  solutions  or  even 

surface  system  solutions  would  need  huge  efforts  to  adapt  the  system  to  the  ship  and 
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would  also  cause  a  tremendous  redesign  of  the  ship.  The  need  for  a  quickly  deployed 
system  emphasizes  an  exclusion  of  subsurface  and  surface  systems  as  solutions,  too. 
Therefore,  the  IPT  should  consider  aerial  solutions  regarding  the  principal  systems  design 
only,  but  it  should  not  focus  on  one  aerial  solution  only.  Many  different  solutions  for  an 
aerial  system  can  be  taken  into  consideration,  such  as  conventional  ASW  helicopters  of 
different  types  or  various  types  of  unmanned  solutions. 

7.  Requirements  Management 

a.  Introduction 

Allen  N.  (2008)  states  that  requirements  management  shall  be  conducted 
throughout  a  project’s  life-cycle.  He  explains  that  systems  engineering  accomplishes 
activities  and  processes  to  decompose  the  approved  need  into  a  progressively  defined 
system  as  well  as  a  component  requirement  which  results  in  a  system  design  that  can  be 
tested,  produced,  and  fielded  to  satisfy  the  need.  The  concept  development  phase  enables 
us  to  detennine  the  most  appropriate  solution,  and  this  phase  often  entails  parallel  study 
efforts,  which  includes  various  alternatives.  These  basic  requirements  are  typically  stated 
in  general  terms  and  do  not  provide  a  sufficient  level  of  detail  to  enable  a  system  design. 
Accordingly,  the  development  of  operational  requirements  closely  follows  the  systems 
design  process  to  provide  the  needed  capability,  but  different  solutions  for  the  same  need 
might  also  have  different  operational  requirements  systems.  Allen  (2008)  underlines  this 
statement  with  an  example  of  a  deep-attack  need  which  could  be  addressed  by  a  deep- 
attack  aircraft  or  a  surface-to-surface  missile.  Both  examples  may  have  the  same 
requirements  but  some  other  ones  would  differ  dramatically.  Therefore,  the  operational 
concept  and  requirements  must  be  redefined  later  in  accordance  with  the  identified  basic 
design  solutions  to  contribute  to  the  design  process  and  to  determine  operational 
requirements  in  terms  of  thresholds  and  objectives.  The  most  important  and  critical 
operational  requirements  are  the  key  performance  parameters  (KPP).  The  operational 
requirements  thresholds  and  objectives,  and  in  particular  the  KPPs,  are  needed  later  in  the 
decision-making  process  to  measure  and  evaluate  the  overall  performance  of  the  various 
solutions  regarding  the  level  of  fulfillment  to  cover  the  capability  gap. 
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b.  Basic  Requirements  of  the  Need 

The  requirements  of  the  Need  can  be  separated  into  the  two  sub¬ 
requirements:  function  and  performance.  According  to  Allen  (2008)  a  functional 
requirement  identifies  what  the  system  must  accomplish,  and  a  performance  requirement 
identifies  how  well  the  system  must  perfonn  in  the  environment  in  which  it  operates. 
Furthennore,  the  nature  of  a  good  requirement  concerns  the  user  who  benefits  from  the 
requirement  and  the  state  the  user  wishes  to  reach  in  respect  to  details  and  performance 
metric,  and  In  addition,  it  must  be  feasible  to  determine  how  the  requirement  can  be 
evaluated. (Miller,  2012).  Good  requirements  should  fulfill  following  criteria: 

•  Must  be  verifiable. 

•  Can  be  evaluated  and  tested. 

•  Should  not  be  defined  by  words  such  as  “excessive,”  “sufficient,” 
“resistant,”  etc. 

•  Must  be  unambiguous. 

•  Must  be  complete. 

•  Should  be  consistent  with  other  requirements. 

•  Must  contain  all  mission  profiles,  operational  and  maintenance 
concepts,  utilization  environments,  and  constraints. 

Defining  requirements  is  not  a  “one  man  show.”  As  already  noted  in  the 
preceding  process  steps,  the  effort  requires  the  entire  IPT  to  work  as  a  team  and 
particularly  as  the  user. 

The  Functional  Flow  Block  Diagram  delivers  most  of  the  infonnation 
from  which  to  derive  basic  functional  requirements.  Additionally,  a  good  way  to  derive 
requirements  is  to  think  about  basic  scenarios  in  respect  to  a  specific  task  the  system  shall 
perfonn.  Basic  scenarios  can  be  developed  from  the  stakeholder  elicitation  results  and 
knowledge  of  an  ASW  basic  operational  concept.  The  infonnation  illustrated  in  the 
Functional  Flow  Block  Diagram  (Figure  32)  and  the  Component  Breakdown  (Figure  31) 
support  the  definition  of  requirements  very  effectively  also.  The  intended  user  (the  ASW 
community)  should  also  be  involved  to  support  the  IPT  in  developing  the  requirements. 
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c.  Basic  Functional  Requirements  in  Respect  to  the  CPM’s  FFF- 
Document 

As  already  explained  in  the  background  of  this  thesis,  the  FFF  describes 
the  capability  gap  and  the  functional  requirements.  The  FFF  document  shall  include 
infonnation  about  the  following  areas: 

•  Designation  of  the  required  capability  (Need) 

•  Extrapolation  of  the  capability  from  reference  documents  and  a 
description  of  the  capability  gap 

•  Description  of  the  functional  requirements  and  project  elements 

It  can  be  summarized  that  the  first  two  bullet  points  have  been  delivered  in 
the  preceding  chapters.  The  next  step  concerning  the  CPM  is  the  necessary  description  of 
the  functional  requirements  without  having  a  certain  solution  in  mind.  The  Preliminary 
Design  Analysis  has  already  indicated  that  due  to  some  constraints  only  aerial  solutions 
should  be  taken  into  consideration. 

The  effective  need  in  addition  to  infonnation  and  constraints  detennined 
through  the  Stakeholder  Analysis  and  Boundaries  Definition  enables  us  to  derive  basic 
functional  requirements  for  an  aerial  ASW  system.  Unfortunately  the  FFF  document 
demands  only  a  description  of  functional  requirements;  it  does  not  demand  non¬ 
functional  requirements.  A  system  has,  of  course,  both  kinds  of  requirements  and  cannot 
be  comprehensively  defined  by  only  functional  ones.  Therefore,  this  thesis  will  consider 
functional  and  non-functional  requirements. 

The  basic  functional  and  non-functional  requirements  for  an  organic  and 
aerial  ASW  system: 

•  The  user  shall  be  able  to  accommodate,  to  embark,  and  to  use  the 
system  as  organic  an  ASW  system  on  board  the  F123,  F124,  F125 
and  MKZ  180. 

•  The  user  shall  be  able  to  maintain  the  system  on  board  the  ship 
during  the  time  of  embarkation. 

•  The  user  shall  be  able  to  deploy  the  system  quickly  to  the 
designated  ASW  mission  area. 

•  The  user  shall  be  able  to  search,  track,  and  identify  submerged 
submarines  by  using  a  dipping  sonar. 

•  The  user  shall  be  able  to  process  sonar  data  to  the  system’s  ASW 
data  processing  device. 
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•  The  user  shall  get  displayed  and  already  processed  search  and  track 
dipping  sonar  data  of  the  possible  threat. 

•  The  user  shall  be  able  to  send  sonar  data  to  other  ASW  units  in  HF 
and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  receive  sonar  data  from  other  ASW  units 
in  HF  and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  search,  track,  and  identify  submerged 
submarines  by  using  sonobuoys. 

•  The  user  shall  be  able  to  process  sonar  data  to  the  system’s  ASW 
data  processing  device. 

•  The  user  shall  get  displayed  and  already  processed  search  and  track 
sonobuoy  data  of  the  possible  threat. 

•  The  user  shall  be  able  to  send  sonar  data  to  other  ASW  units  in  HF 
and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  receive  sonar  data  from  other  ASW  units 
in  HF  and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  deploy  dipping  sonar  and  sonobuoys 
simultaneously. 

•  The  user  shall  be  able  to  search,  track,  and  identify  snorkeling  and 
surfaced  submarines  by  using  electro-optical  devices. 

•  The  user  shall  be  able  to  process  electro-optical  data  to  the 
system’s  ASW  data  processing  device. 

•  The  user  shall  be  able  to  send  electro-optical  data  to  other  ASW 
units  in  HF  and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  receive  electro-optical  and  infrared  data 
from  other  ASW  units  in  HF  and  VHF/UHF  frequency  (Network 
capability). 

•  The  user  shall  be  able  to  search,  track,  and  identify  snorkeling  and 
surfaced  submarines  by  using  Radar. 

•  The  user  shall  be  able  to  process  Radar  data  to  the  system’s  ASW 
data  processing  device. 

•  The  user  shall  be  able  to  send  Radar  data  to  other  ASW  units  in  HF 
and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  receive  Radar  data  from  other  ASW  units 
in  HF  and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  search,  track,  and  identify  transmitting 
submarines  by  using  electronic  warfare  system  (EWS). 

•  The  user  shall  be  able  to  process  EWS  data  to  the  system’s  ASW 
data  processing  device. 

•  The  user  shall  be  able  to  send  EWS  data  to  other  ASW  units  in  HF 
and  VHF/UHF  frequency  (Network  capability). 

•  The  user  shall  be  able  to  receive  ESM  data  from  other  ASW  units 
in  HF  and  VHF/UHF  frequency  (Network  capability). 
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•  The  user  shall  be  able  to  receive  and  send  information  and  data 
from  other  assets  (outside  the  boundaries  of  the  “System  of 
Systems”)  in  HF,  VHF/UHF  frequency,  and  satellite  (Network 
capability). 

•  The  user  shall  be  able  to  engage  submerged  and  surfaced  hostile 
submarines  successfully  by  using  lethal  or  non-lethal  weapons. 

d.  Basic  Performance  Requirements 

The  perfonnance  requirements  concern  the  performance  in  respect  to 
sensors,  weapons,  and  the  performance  of  the  system  itself  in  terms  of  speed,  flight-level, 
endurance,  environment,  communication,  etc.  They  are  related  to  functional  requirements 
and  describe  the  perfonnance  of  some  functions.  The  perfonnance  requirement  should,  of 
course,  be  delivered  by  the  stakeholders,  particularly  from  the  users  of  the  ASW  system. 
In  particular,  future  system  operators,  maintainers,  logisticians,  and  also  peer  system 
users  are  requested  to  present  and  explain  the  performance  requirement  figures  and 
numbers.  Because  these  are  not  available  for  this  thesis,  an  “x”  is  used  as  a  placeholder 
for  real  ones.  The  basic  performance  requirements  for  a  ship-bome  aerial  ASW  system 
include  the  following: 

•  The  user  shall  be  able  to  handle  and  move  the  system  on  board 
from  hangar  to  flight  deck,  and  vice  versa  with  the  ships  handling 
devices  up  to  sea-state  level  “x”. 

•  The  user  shall  be  able  to  maintain  for  all  routine  level  maintenance 
the  system  in  the  hangar  in  level  1  and  2  during  the  time  of 
embarkation. 

•  The  user  shall  be  able  to  maintain  the  aerial  system  with  lesser 
maintenance  hours  as  needed  for  the  MH90. 

•  The  user  shall  be  able  to  maintain  a  higher  average  operational 
availability  for  the  aerial  system  than  the  MH90  does  have. 

•  The  user  shall  be  able  to  supply  the  system  with  an  embarked 
spare-part  stock  with  a  safety  level  of  “x”  %. 

•  The  user  shall  be  able  to  prepare  the  aerial  system  for  take-off  and 
to  conduct  take-off  the  aerial  system  up  to  sea-state  level  “x” 
within  “x”  minutes. 

•  The  aerial  system  shall  be  able  to  reach  the  designated  ASW 
mission  area  with  a  minimum  speed  of  “x”  kts  (IAS). 

•  The  aerial  system  shall  be  able  conduct  an  automatic  flight 
transition  from  forward  flight  to  hover  for  deploying  dipping  sonar 
to  the  selected  position  within  “x”  minutes. 
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•  The  aerial  system  shall  be  able  to  hover  steadily  for  several 
minutes  in  position  even  in  severe  weather. 

•  The  user  shall  be  able  to  search,  track  precisely,  and  identify 
reliable  and  certain,  submerged  submarines  with  a  dipping  sonar 
with  a  perfonnance  that  is  at  least  equivalent  to  the  MH90. 

•  The  user  shall  be  able  to  lower  the  transducer  of  the  dipping  sonar 
to  selected  a  depth  within  “x”  minutes. 

•  The  aerial  system  shall  be  able  to  retract  the  transducer  of  the 
dipping  sonar  within  “x”  minutes. 

•  The  aerial  system  shall  be  able  to  reach  the  next  dipping  position 
from  hover  to  hover  within  “x”  minutes. 

•  The  user  shall  be  able  to  conduct  a  sustained  dipping-sonar  mission 
with  a  minimum  of  “x”  sonar  dips  at  least  up  to  “x”  hours  at  a 
distance  of  at  least  “x”  miles. 

•  The  system  shall  be  able  to  deploy  up  to  “x”  sonobuoys  during  a 
mission  cycle. 

•  The  system  shall  be  able  to  deploy  up  to  “x”  sonobuoys  at 
detennined  positions  within  “x”  minutes. 

•  The  user  shall  be  able  to  search,  track  precisely,  and  identify, 
reliable  and  certain,  submerged  submarines  with  sonobuoys  with  a 
perfonnance  that  is  at  least  equivalent  to  the  MH90. 

•  The  user  shall  be  able  to  search,  track,  and  identify,  reliable  and 
certain,  surfaced  submarines  with  a  radar  with  a  performance  that 
is  at  least  equivalent  to  the  MH90. 

•  The  user  shall  be  able  to  search,  track  precisely,  and  identify, 
reliable  and  certain,  surfaced  submarines  with  electro-optical  and 
infrared  with  a  perfonnance  that  is  at  least  equivalent  to  the  MH90. 

•  The  user  shall  be  able  to  search,  track  precisely,  and  identify, 
reliable  and  certain,  transmitting  submarines  with  an  EWS  with  a 
perfonnance  that  is  at  least  equivalent  to  the  MH90. 

•  The  aerial  system  shall  be  able  to  send  and  receive  encrypted  data 
of  all  its  sensors  to  other  ASW  units  in  HF  and  VHF/UHF 
frequency  without  delay. 

•  The  system  (within  the  System  of  Systems)  shall  be  able  to  send 
data  of  all  its  sensors  to  other  friendly  units  in  HF  and  VHF/UHF 
frequency  and  satellite  without  delay. 

•  The  user  shall  be  able  to  survive  hostile  attacks  with  a  probability 
of“x”% 

•  The  system  shall  be  able  to  operate  in  extreme  environments. 

•  The  system  shall  not  be  inhibited  by  icy  weather  conditions. 

•  The  system  shall  not  be  inhibited  by  stormy  and  rainy  weather 
conditions. 
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It  is  important  that  functional  requirements  are  not  combined  with 
operational  requirements  at  this  point.  That  will  happen  at  a  later  step  in  the  process  when 
functional  requirements,  design,  and  operational  requirements  will  be  formulated  to 
certain  system  perfonnance  specifications.  The  presented  functional  and  performance 
requirements  will  not  meet  all  previously  identified  attributes  of  good  requirements  at 
that  process  stage.  Requirements  are  insufficient  for  designing  a  solution  and  must  be 
translated  into  specifications  that  can  be  tested  or  verified.  The  requirements  presented 
earlier  are  the  minimum  necessary  to  allow  the  design  process  to  find  alternative 
solutions  based  on  functional  requirements.  Accordingly  the  basic  functional  and 
performance  requirements  must  be  redefined  later  during  the  next  design  processes  when 
a  proposed  design  and  possible  alternative  solutions  have  been  established.  Then,  the 
redefined  and  improved  functional,  performance,  and  operational  requirements  will  be 
translated  and  fused  into  system  specifications  which  should  then  conform  to  the 
previously  identified  attributes  of  good  requirements. 

8.  Expected  Future  Life-Cycle  and  Life-Cycle  Costs  for  the  FFF- 

Document 

a.  Introduction 

The  US  Defense  Acquisition  Guidebook  (Under  Secretary  of  Defense 
(AT&L),  2011)  defines  that  Life-Cycle  Cost  (LCC)  in  general  terms: 

Life-cycle  cost  consists  of  research  and  development  costs,  investment 
costs,  operating  and  support  costs,  and  disposal  costs  over  the  entire  life 
cycle.  These  costs  include  not  only  the  direct  costs  of  the  acquisition 
program,  but  also  include  indirect  costs  that  would  be  logically  attributed 
to  the  program.  In  this  way,  all  costs  that  are  logically  attributed  to  the 
program  are  included,  regardless  of  funding  source  or  management 
control.  Program  cost  estimates  that  are  supporting  the  defense  acquisition 
system  normally  are  focused  on  life-cycle  cost  or  elements  of  life-cycle 
cost. 


The  German’s  CPM  Analysis  Phase,  which  is  the  concern  of  Chapter  III, 
is  a  pre-acquisition  phase.  No  funding  has  been  approved,  and  no  program  has  been 
initiated  in  that  phase.  The  FFF  document  is  to  some  extent  comparable  to  the  U.S.-ICD 
(Initial  Capability  Document).  At  that  early  stage  no  certain  solution  and  design  has  been 
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selected;  accordingly  no  detailed  calculations  concerning  life-cycle  costs  can  be  done. 
Only  broad  considerations  and  estimations  could  be  delivered  by  the  IPT  for  the  FFF 
document. 


The  U.S.  Defense  Acquisition  Guidebook  (2011)  explains  this  cost  issue  at 

this  phase: 

However,  for  programs  in  Pre-Systems  Acquisition  or  the  Engineering  and 
Manufacturing  Development  Phase,  cost  estimates  that  are  used  within  the 
program  office  to  support  system  trade-off  analyses — such  as  evaluations 
of  design  changes,  or  assessments  of  energy  efficiency,  reliability, 
maintainability,  and  other  supportability  considerations — may  need  to  be 
broader  in  scope  than  traditional  life-cycle  cost  estimates  to  support  the 
purpose  of  the  analyses  being  conducted.  Moreover,  for  mature  programs 
(in  transition  from  production  and  deployment  to  sustainment),  cost 
estimates  in  many  cases  may  need  to  be  expanded  in  scope  to  embrace 
total  ownership  cost  concepts  in  order  to  support  broad  logistics  or 
management  studies. 

Furthennore,  the  Guidebook  explains  that: 

“Life-cycle  cost  can  be  defined  as  the  sum  of  four  major  cost  categories, 
where  each  category  is  associated  with  sequential  but  overlapping  phases  of  the  program 
life  cycle.  Life-cycle  cost  consists  of: 

1 .  research  and  development  costs  associated  with  the  Materiel  Solution 
Analysis  phase,  the  Technology  Development  phase,  and  the 
Engineering  and  Manufacturing  Development  phase, 

2.  investment  costs  associated  with  the  Production  and  Deployment 
phase, 

3.  operating  and  support  costs  associated  with  the  sustainment  phase, 
and 

4.  disposal  costs  occurring  after  initiation  of  system  phase  out  or 
retirement,  possibly  including  demilitarization,  detoxification,  or  long¬ 
term  waste  storage.” 
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Total  Life  Cycle  Cost 


Research  &  Production  &  Operations  Disposal 

Development  Deployment  &  Support 

Figure  34.  Composition  of  total  life-cycle  costs. 


The  nature  of  many  programs  is  that  the  cost  over  time  increases  at  each 
step  of  a  program.  Every  program  shows  different  amounts  of  cost  corresponding  to  each 
of  its  phases.  Because  of  the  complexity  of  programs,  their  associated  costs  other  than 
those  associated  with  acquisition  are  not  readily  apparent  (Figure  35)..  Often,  only 
research  and  investment  costs  are  taken  into  consideration  by  decision  makers  when  they 
go  for  an  alternative,  because  these  two  phases  are  usually  separately  funded  from 
Operations  and  Support  (O&S)  and  disposal.  That  practice  applies  for  German  Armed 
Forces  as  well. 
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Figure  35.  Visibility  of  LCC-Elements  (Blanchard,  Fabrycky  2011). 
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In  an  early  stage  of  the  Research  and  Development  (R  &  D)  phase  the 
O&S  cost  are  vague  due  to  the  lack  of  detailed  information  for  calculations.  This  is 
particularly  true  if  it  concerns  programs  with  a  new  technology  (Figure  36).  These 
programs  are  often  involved  in  high  cost  overruns  in  respect  to  early  life-cycle  costs 
estimations,  and  that  happens  already  during  the  R&D  and  Investment  phases. 

The  F-35  is  currently  a  good  example  for  that  problem.  The  F  35  cost 
problems  may  aggravate  when  the  program  enters  the  O&S  phase,  where  the  partition  of 
the  entire  life-cycle  costs  is  even  higher  than  R&D  and  Investment  together. 


iricKKccn 


w( mere*  uc  m.'x  "va/ib*  rwi« 


Figure  36.  Life-cycle  cost  according  to  Defense  Acquisition  Guidebook  (Under  Secretary  of 

Defense  (AT&L),  2011). 

If  the  future  program  is  a  System  of  Systems,  then  life-cycle  costs 
calculations  may  not  be  sufficient  or  comprehensive  enough  to  determine  the  real  cost  for 
a  Need.  That  is  because  the  program  concerns  more  than  a  single  system,  as  may  be  the 
ASW  case.  A  possible  future  solution  to  cover  the  gap  could  involve  some  more 
stakeholders  (other  aerial  systems,  vessels,  etc.)  in  respect  to  the  costs,  which  are  not  part 
of  the  traditional  life-cycle  cost  calculation.  It  may  be  advisable  to  take  costs  in  respect  to 
the  total  ownership  into  consideration  instead  life-cycle  costs  only. 
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Once  more,  the  guidebook  describes  this  consideration: 

Total  ownership  cost  includes  the  elements  of  a  program's  life-cycle  cost, 
as  well  as  other  related  infrastructure  or  business  processes  costs  not 
necessarily  attributed  to  the  program  in  the  context  of  the  defense 
acquisition  system.  Infrastructure  is  used  here  in  the  broadest  possible 
sense,  and  consists  of  all  military  department  and  defense  agency  activities 
that  sustain  the  military  forces  assigned  to  the  combatant  and  component 
commanders. 

In  general,  traditional  life-cycle  cost  estimates  are  often  adequate  in  scope 
to  support  the  review  and  oversight  of  cost  estimates  made  as  part  of  the  acquisition 
system.  However,  in  special  cases,  depending  on  the  issue  at  hand,  the  broader 
perspective  of  total  ownership  cost  may  be  more  appropriate  than  the  life-cycle  cost 
perspective,  which  may  be  too  narrow  to  deal  with  the  particular  context.  As  discussed 
previously,  for  a  defense  acquisition  program,  life-cycle  costs  include  not  only  the  direct 
costs  of  the  program,  but  also  certain  indirect  costs  that  would  be  logically  attributed  to 
the  program.  In  a  typical  life-cycle  cost  estimate,  however,  the  estimated  indirect  costs 
would  include  only  the  costs  of  infrastructure  support  specific  to  the  program's  military 
manpower  (primarily  medical  support  and  system-specific  training)  and  the  program's 
associated  installations  or  facilities  (primarily  base  operating  support  and  facilities 
sustainment,  restoration,  and  modernization). 

b.  Life-Cycle  Cost  for  the  ASW  Need 

The  FFF  document  requests  some  numbers  concerning  the  time-frame  of 
intended  usage  and  life-cycle  costs.  The  first  part  of  the  CPM’s  Analysis  phase  explicitly 
does  not  ask  for  a  certain  solution;  rather  it  asks  for  a  neutral  description  of  the  Need. 
Accordingly,  the  already  applied  systems  engineering  processes  helped  us  to  understand 
the  stakeholder  needs  and  boundaries  and  to  define  the  Need  definition.  The  constraints 
and  boundaries  enabled  us  to  limit  the  basic  design  to  an  aerial  one  and  maybe  to  identify 
it  as  a  System  of  Systems.  That  means  many  different  alternatives  could  still  be 
developed,  and  only  one  will  be  the  solution.  That  fact  makes  it  difficult  to  estimate  any 
life-cycle  costs  on  a  sound  basis.  It  is  understood  that  decision  makers  need  some 
numbers  to  approve  and  fund  further  research.  However,  it  is  not  legitimate  to  expect 
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sharply  calculated  life-cycle  numbers  and  costs  for  a  Need  from  the  IPT.  Instead,  the  IPT 
should  deliver  life-cycle  cost  estimations  which  cover  the  possible  range  (max -min)  of 
the  costs. 


The  Program  Manager’s  Tool  Kit  (Under  Secretary  of  Defense  (AT&L). 
2009)  takes  that  problem  into  consideration  and  describes  four  different  ways  to  estimate 
costs  (Figure  37): 


Estimate  Methods  Comments 


Analogy 


Parametric 


Engineering  or 
“Bottoms-Up" 


Extrapolation 


Companson  to  one  similar  existing  system; 
based  on  judgments.  Little  or  no  data  available; 
relatively  quick,  easy,  flexible  Used  in  early  phases 
(e  g..  Material  Solution  Analysis  and  Tech.  Dev.) 

Comparison  to  many  similar  existing  systems; 
based  on  statistical  analysis.  Determine 
primary  cost  drivers  and  establish  Cost 
Estimating  Relationships  (CERs).  Used  in  early 
to  mid-phases  (e  g  .  Material  Solution  Analysis. 
Tech  Dev ,  and  Engr  and  Manufacturing  Dev.) 

Summation  of  "all"  individual  items  in  the  system. 
Uses  Work  Breakdown  Structure  (WBS) 
for  estimating  purposes  Used  in  mid-phases 
(e  g..  Engineering  and  Manufacturing  Development) 

Comparison  to  historical  cost  of  same  system. 
Based  on  extrapolation  from  actuals.  Uses 
Learning  Curve  Theory.  Used  in  late  phases 
(e  g..  Production  and  Operations/Support) 


Figure  37.  Costs  estimate  methods  according  to  DAU  Program  Manager’s  Tool  Kit. 


Regarding  the  German  ASW  capability  Need  and  due  to  the  early  phase  of 
the  CPM,  only  the  Analogy  Method  seems  to  be  applicable.  This  method  is  also  advised 
by  the  Tool  Kit  for  early  phases. 

The  MK  88A  “Sea  Lynx”  has  been  in  use  for  decades  and  is  the 
predecessor-system  of  the  Need;  thus  the  Navy  should  have  the  real  life-cycle  costs  for 
that  weapon  system.  By  requesting  these  figures  and  updating  these  numbers  in  terms  of 
current/future  Euro  the  IPT  can  set  the  “Sea  Lynx”  costs  as  minimum  expected  life-cycle 
costs.  Some  people  may  disagree  with  this  method.  However,  even  when  these  numbers 
do  not  precisely  correlate  to  the  new  system  (Need),  they  are  still  real,  reasonable,  and 
preferable  to  random  estimation.  Additionally,  figures  from  the  current  procurement  and 
operation  of  the  NH90  (Army  variant)  are  available  and  can  be  used  as  maximum 
expected  life-cycle  costs.  If  some  similar  research,  efforts,  and  programs  in  NATO  or 
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Allies  exist,  then  data  and  program  information  should  be  requested  from  these  sources 
and  subsequently  adapted  for  our  own  cost  estimations.  By  the  way,  the  request  of  the 
FFF  document  concerning  the  expected  future  user  has  been  already  detennined  by  the 
Stakeholder  Analysis. 

9.  Summary  and  Conclusion 

The  Systems  Engineering  processes  are  applicable  in  the  FFF  Analysis  phase  and 
help  to  illuminate  the  ASW  capability  Need  thoroughly.  The  processes  enable  us  to 
identify  and  understand  the  “wants  and  needs”  of  the  stakeholder,  and  also  to  identify  and 
to  select  the  most  important  needs.  Additionally,  the  determination  of  the  boundaries  and 
top-level  functions  allowed  for  a  redefinition  of  the  problem  statement.  Finally,  an 
effective  need  could  be  developed  from  the  early  primitive  Need  that  enables  the  IPT  to 
understand  the  true  nature  of  the  need.  Accordingly,  with  all  that  information,  the  design 
alternatives  can  be  limited  to  an  aerial  system,  and  its  basic  functional  requirements  can 
be  derived.  Estimating  life-cycle  cost  is  the  last  step  in  a  comprehensive  and  complex 
process  of  presenting  a  sound  FFF  document.  If  the  FFF  document  is  approved,  the 
BAAINBw  and  its  IPT  can  continue  with  the  second  part  of  the  CPM’s  Analysis  phase. 
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V.  SYSTEMS  ENGINEERING  AND  THE  CPM’S  ANALYSIS 

PHASE:  PART  2 


A.  ANALYSIS  PHASE  PART  2:  DESIGN  AND  ANALYSIS  OF 

ALTERNATIVE  SOLUTIONS 

The  second  part  of  the  analysis  phase  concerns  the  physical  component  analysis 
and  shall  identify  technical  and  design  solutions  (alternatives)  to  meet  the  requirements. 
The  alternative  solutions  can  be  differentiated  into  categories  of  employment  of  already 
available  products  and  use  of  existing  services,  improvement  of  “in  service”  systems,  and 
development  of  new  products.  The  IPT  has  to  provide  at  least  one  solution  that  meets  all 
the  functional  requirements  and  other  solutions  that  meet  at  least  the  time  and  cost  frame 
of  the  FFF.  A  proposal  of  all  alternative  solutions  has  to  be  presented  to  Chief  of  Federal 
Armed  Forces  Staff  (CoS)  by  the  MoD  Directorate  of  Equipment,  Information 
Technology,  and  In-Service  Support.  The  solutions  can  be  categorized  into: 

•  Procurement  of  available  products 

•  Improvement  (adaption)  of  in-service  materiel 

•  Realization  of  new  products 

The  IPT  has  to  follow  the  CPM  document-given  tasks  when  developing  the 
solutions.  These  tasks  include  the  following: 

•  Sighting  and  assessing  of  available  products 

•  Assessing  the  improvement  (adaption)  potential  of  in-service  materiel 

•  Assessing  the  realization  of  new  products 

•  Assessing  possible  national  and  international  cooperation 

•  Considering  obsolescence 

•  Detennining  demand  (amount) 

•  Planning  and  scheduling  of  the  life-cycle 

•  Detennining  resources  for  Testing 

•  Estimating  the  logistic  footprint 

•  Illustrating  risk  in  respect  to  realization  and  operation 

•  Detennining  life-cycle  costs 

•  Estimating  time  period  and  funding  for  the  realization  and  operation  phase 

•  Assessing  the  degree  of  fulfillment  in  respect  to  the  requirements  stated  in 
the  FFF-document 

Possible  solutions  need  to  be  analyzed  and  assessed  with  respect  to  performance, 
time,  costs,  and  risk  against  the  background  of  research  and  technology  to  be  used.  The 
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BAAINBw  can  contract  companies  to  support  research  on  feasible  solutions  by 
conducting  modeling,  simulation,  and  prototyping  to  evaluate  the  technical  feasibility  of 
the  possible  product.  To  reduce  risk  an  incremental  procurement  process,  which  leads  to 
the  fulfillment  of  the  requirements  according  to  the  FFF-document,  can  be  taken  into 
consideration,  if  appropriate. 

The  CoS  decides  which  solution  will  be  selected  and  continued  as  a  procurement 
program.  Accordingly,  for  each  proposed  solution  a  design  needs  to  be  researched  and 
developed  by  the  IPT  and  presented  to  the  decision  makers.  This  thesis  will  cover  some 
of  the  above  mentioned  tasks  which  can  be  detennined  using  systems  engineering 
processes. 

B.  APPLYING  SYSTEMS  ENGINEERING 
1.  System  Design  and  Synthesis 
a.  Introduction 

Allen  (2008)  explains  that  synthesis  defines  a  design  solution  which  will 
satisfy  the  requirements  of  the  verified  functional  architecture  and  translate  the  functional 
architecture  into  a  physical  architecture  of  system  elements.  This  describes  a  system 
design  that  emerges  from  the  functional  requirements.  He  states  that  this  synthesis 
involves  selecting  a  preferred  design  solution  from  a  set  of  alternatives.  The  V-model 
depicted  in  the  DAU  PM  Tool  Kit  (Under  Secretary  of  Defense  (AT&L),  2009)  illustrates 
once  more  the  next  step  within  the  design  processes  (Figure  38). 
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Figure  38.  SEP  and  technical  management  processes  in  respect  to  second  part  of  the  analysis 

phase. 

Finding  the  right  design  is  the  last  step  before  decision  makers  have  to 
decide  which  one  will  be  developed.  The  IPT  shall  present  some  thoroughly  derived 
physical  designs  which  can  be  assessed  by  an  analysis  of  alternative  (AoA)  processes. 
The  process  of  “Systems  design  and  synthesis”  will  support  the  IPT  to  develop  some 
designs  (solutions)  derived  from  the  functions  and  requirements  to  physical  subjects  and 
designs. 


b.  Functional  Analysis  of  the  Need 

The  functional  analysis  is  a  process  that  allows  for  the  combination  of 
basic  requirements  and  functions  into  a  functional  architecture.  It  defines  the  functions 
necessary  to  accomplish  the  requirements.  It  decomposes  functional  requirements  (what 
must  be  done)  and  performance  requirements  (how  well  must  it  be  done)  into  lower-level 
functions  (Allen  2008).  That  process  enables  us  in  principle  to  decompose  top-level 
functions  into  single  maintenance  works  and  system  usage.  Each  level’s  functions  can  be 

compared  with  some  real-life  scenarios  and  what  must  be  perfonned  within  these  partial 
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scenarios  to  fulfill  a  certain  mission  within  the  “big  picture”  scenario.  A  comprehensive 
application  for  the  development  of  an  actual  functional  architecture  is  not  within  the 
scope  of  the  thesis.  The  following  figure  (Figure  40)  is  an  example  of  how  that  functional 
architecture  illustrates  the  decomposition  of  functional  requirements  and  performance 
requirements,  derived  from  the  example  presented  by  Allen  (2008).  The  illustrated 
example  concerns  a  dipping  sonar  mission  on  level  three  and  four.  The  numbers  in  Figure 
40  are  assumed  performance  requirements.  Although  these  numbers  do  not  come  from 
research,  they  do  approximate  real  ones  and  can  be  used  for  explanation.  To  understand 
the  systems  functions  comprehensively,  the  IPT  should  develop  for  each  second-level 
function  further  lower-level  functional  architecture  diagrams,  such  as  pre  and  post-flight 
activities,  maintenance,  sonobuoys,  mission,  etc.,  to  analyze  and  understand  each 
function  for  all  actions  conducted  with  the  system. 
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Figure  39.  Functional  architecture  levels  1-4. 
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c.  Physical  Architecture  through  Functional  Allocation 

By  allocating  functional  architecture  to  a  physical  architecture,  physical 
components  can  be  identified  and  allocated  to  each  function.  That  process  detennines  the 
function  and  the  physical  component  that  is  required  to  develop  a  physical  design  for  the 
need.  Allen  (2008)  describes  that  process  as  a  synthesis  of  requirements  and  functions 
for  defining  a  design  by  translating  functional  architecture  in  a  physical  one.  This  step 
also  involves  the  selection  of  the  basic  preferred  design.  As  already  stated,  the  preferred 
design  is  an  aerial  one  within  the  context  of  a  System  of  Systems  which  involves  ships 
and  other  aerial  assets. 
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The  allocation  of  functions  to  basic  physical  components  and  a  description 
of  functions  and  requirements  is  shown  in  Figure  40. 


Function 

Physical  Component 

Description  of  Meeting  Function 

and  Requirement 

1.  Fly  to  Mission  Area/to 

Ship 

Airframe 

Airframe  must  be  capable  to  fly  to 

mission  area  within  40  minutes. 

1.1  Start  from  Organic 

Ship 

Airframe 

Airframe  must  be  capable  to  start 

from  board  their  organic  ship  at 

Sea  State  6  within  1  minute. 

1.2  Land  on  Organic  Ship 

Airframe 

Airframe  must  be  capable  to  land 

board  their  organic  ship  at  Sea 

State  6  within  1  minute. 

2.  Search,  Track,  Identify 

2.1  Dipping  Sonar  Search 

2.1.1  Hover  over 

dipping 

position 

Airframe 

Airframe  must  be  capable  for 

steady  vertical  flight  and  hover  for 

dipping  sonar  in  severe  weather 

conditions  for  10  minutes. 

2.1.2  Deploy/recover 

transducer 

Dipping  sonar  system 

Dipping  sonar  system  is  required 

to  lower/recover  a  sonar 

transducer  within  2  minutes. 

2.1.3  Search 

Dipping  sonar  system 

Dipping  sonar  system  is  required 

to  send  and  receive  sonar  signals. 

2.1.4  Track 

Dipping  sonar  system 

Dipping  sonar  system  is  required 

to  track  sonar  signals. 

2.1.5  Identify 

Dipping  sonar  system 

Dipping  sonar  system  is  required 

to  identify  sonar  signals. 
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2.2.  Surface  Sensor  and 
Sonobuoy  Search 


2.2.1  Cruise  flight 

over 

search 

area 

Airframe 

Airframe  must  be  able  for  flight  in 

different  heights  in  severe 

weather. 

2.2.2  Search  with 

radar 

Radar  system 

Radar  must  be  capable  to  detect 

surfaced  submarines  and 

submerged  submarines  with 

deployed  snorkel. 

2.2.3Trackwith 

radar 

Radar  system 

Radar  must  be  capable  to  track 

surfaced  submarines  and 

submerged  submarines  with 

deployed  snorkel. 

2.2.4  Identify  with 

radar 

Radar  system 

Radar  must  be  capable  to  identify 

surfaced  submarines . 

2.2.5  Search  with 

EO/IR 

EO/IR  system 

EO/IR  system  must  be  capable  to 

detect  surfaced  submarines  and 

submerged  submarines  with 

deployed  snorkel. 

2.2.6Track  with 

EO/IR 

EO/IR  system 

EO/IR  system  must  be  capable  to 

track  surfaced  submarines  and 

submerged  submarines  with 

deployed  snorkel. 

2.2.7  Identify  with 

EO/IR 

EO/IR  system 

EO/IR  system  be  capable  to 

identify  surfaced  submarines. 
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2.2.8  Search  with 

EWS 

EWS  system 

EWS  system  must  be  capable  to 

detect  transmitting  submarines. 

2.2.9  Track  with  EWS 

EWS  system 

EO/IR  system  must  be  capable  to 

track  transmitting  submarines. 

2.2.10  Identify  with 

EWS 

EWS  system 

EO/IR  system  be  capable  to 

identify  transmitting  submarines. 

2.1.11  Deploy 

sonobuoys 

Sonobuoy  system 

Sonobuoy  system  is  required  to 

deploy  sonobuoys  at  position. 

2.1.12  Search 

Sonobuoy  system 

Sonobuoy  system  is  required  to 

send  and  receive  sonar  signals. 

2.1.13  Track 

Sonobuoy  system 

Sonobuoy  system  is  required  to 

track  sonar  signals. 

2.1.14  Identify 

Sonobuoy  system 

Sonobuoy  system  is  required  to 

identify  sonar  signals. 

3.  Process  all  Sensor  Data 

and  Confirm 

Mission  data 

processing  and 

management  system 

The  systems  mission  data 

processing  system  must  be 

capable  to  compute  and  process 

all  sensor's  and  received  data. 

4.  Send  and  Receive 

HF-radio;  UHF/VHF- 

radio,  LINK  11,  LINK 

16,  and  LINK  22, 

en/decrypting  system, 

antennas 

The  systems  radios,  data  link, 

decrypting  system,  and  antennas 

are  required  to  communicate  and 

send/receive  data  to/from  organic 

ship  and  other  peer  systems. 

5.  Encounter  Threat 

Torpedoes,  bombs, 

missiles, 

The  systems  anti-submarine 

weapons  are  required  to  deny, 

disable  or  to  destroy  tracked 

hostile  submarines  in  the  mission- 

area. 

Figure  40.  Function  to  physical  architecture  for  the  ASW  need  system. 
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d.  Refining  Requirements  and  Key  Performance  Parameters 

Systems  engineering  inherently  iterates,  reconsiders  and  repeats 
methodologies  implemented  using  feedback  loops  to  improve  and  correct  the  outcomes. 
As  already  stated  in  Chapter  IV,  requirements  management  shall  be  conducted 
throughout  a  project’s  life  cycle.  Therefore,  the  already  defined  operational  concept, 
including  a  maintenance  and  supply  concept,  should  be  refined  and  adapted  in  respect  to 
knowledge  about  alternatives.  The  derived  requirements  should  also  be  refined  in 
accordance  with  the  three  identified  alternative  solutions  to  contribute  to  the  design 
process.  The  users  now  have  a  better  understanding  of  the  possible  solutions  and  can 
refine  and  state  more  precisely  their  operational  requirements.  This  is  particularly 
necessary  because  the  design  architecture  alternative  have  been  extended  by  a  possible 
solution  that  shifts  some  basic  physical  components  to  the  ships.  Accordingly,  the 
operational  concept  and  requirements  in  that  case  are  different  as  these  solutions  are  for 
aerial  systems  only.  The  given  example  of  a  deep-attack  need  which  could  be  a  deep- 
attack  aircraft  or  a  surface-to-surface  missile  may  have  some  of  the  same  requirements, 
but  others  would  differ  dramatically.  The  same  is  true  for  the  alternative  solutions  with 
respect  to  the  capability  shift  to  ships.  Thus,  operational  requirements  would  then  involve 
the  organic  ships  differently  from  the  early  requirements  and  would  need  a  redefinition 
by  the  users. 

Furthermore,  KPP  should  be  derived  from  the  most  critical  operational 
requirements.  The  KPPs  contain  operational  requirements  thresholds  and  objectives. 
They  should  be  directly  traceable  to  the  most  critical  attributes  stated  in  the  FFF 
document.  Additionally,  the  KPPs  should  accomplish  the  following: 

•  Address  the  most  critical  operational  requirements. 

•  Express  requirements  in  terms  of  thresholds  and  objectives 

•  Remain  few  in  number  (eight  or  fewer). 

•  Address  interoperability. 

•  Address  Net-readiness. 

•  Consider  materiel  availability 

•  Be  validated  by  users  and  decision  makers. 

Some  important  and  useful  KPPs  for  the  ASW  need  might  be  following 

ones: 

94 


•  The  system  must  be  embarked,  maintained,  and  operated  on  board 
of  the  FI  23  and  FI  24  frigates  without  adapting  the  hull  structure  of 
the  ships. 

•  The  system  must  be  capable  of  conducting  “x”  sonar  dips  per  hour 
for  “x”  hours  in  a  distance  of  “x”  nautical  miles. 

•  The  system  must  be  capable  of  conducting  an  ASW  patrol  flight 
for  “x”  hours  and  covering  a  patrol  area  of  “x”  nautical  square 
miles 

•  The  system  must  be  capable  of  conducting  ASW  mission  up  to  sea 
state  6,  wind  up  to  60kts,  at  temperatures  between  -30°Celcius  and 
+50°Celcius,  at  all  kind  of  precipitation. 

•  The  system  must  be  capable  of  operating  in  current  and  future 
naval  networks  and  shall  use  ship’s  sonar  data  processing 
capabilities. 

•  The  system  must  be  mission  ready  for  12  hours  continuously  per 
day,  five  days  a  week,  for  three  month  with  an  availability  of  85%. 

e.  Analyzing  the  Physical  Components,  their  Functions,  and 
Requirements  with  respect  to  System  of  Systems 

ASW  systems  work  successfully  only  in  a  team  with  other  peer  ASW 
systems.  Accordingly,  in  an  ASW  mission,  ships  and  aerial  assets  form  a  close  team,  and 
therefore,  a  high  level  of  interoperability  is  required.  The  interoperability  usually 
concerns  software  compatibility  (data  exchange),  rather  than  physical  interoperability. 
Within  the  Gennany  Navy  a  comprehensive  interoperability  between  ASW  assets  is 
given  and  expected.  For  example,  all  helicopters  can  be  serviced  on  all  ships  with  flight 
decks  and  only  one  type  of  torpedo  is  used  on  ship,  helicopter,  and  aircraft.  The  “need” 
system  must  also  have  full  interoperability  features.  In  a  system  of  systems,  multiple 
functions  and  components  are  often  available.  The  relationship  between  ship  and 
helicopter  has  often  been  tenned  as  organic,  because  that  relationship  is  vital  for  mission 
success.  This  vital  relationship  can  be  considered  as  a  system  of  systems,  including  a  ship 
and  an  aerial  asset,  since  each  ship  or  aerial  asset  could  operate  independently  as  a 
systems  in  its  own  right,  but  through  design  we  desire  them  to  operate  as  a  single 
interoperable  system  of  systems.  Therefore,  the  “need”  ASW  system  should  be 
considered  as  a  system  of  systems,  meaning  an  ASW  ship  and  an  aerial  ASW  asset. 
Accordingly,  the  physical  architecture  should  take  both  systems  into  consideration  to  find 
a  design  and  a  solution  for  the  need.  By  their  nature  ASW  ships  and  aerial  assets  are 
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tasked  with  different  missions  in  different  search  areas  within  an  ASW  operation,  but 
multiple  requirements  and  functions  should  be  identified  and  analyzed  if  these  assets  can 
be  used  in  a  complementary  fashion.  When  going  through  the  list  of  physical  components 
shown  in  Figure  40,  mission  data  processing  and  management,  EWS,  and  the  ASW 
weapons  are  the  only  components  which  are  not  unique  to  an  aerial  system  and  which 
exist  on  other  ASW  platfonns.  All  other  components  are  closely  related  to  an  aerial  asset 
and  cannot  be  substituted  by  ships. 

Following  components  are  related  to  aerial  ASW  systems  only. 

•  Airframe:  Today  only  one  principle  design  of  aircraft  is  used  for 
deploying  dipping  sonar;  that  is  the  helicopter.  Only  helicopters  are 
enabled  to  combine  steady  hover  perfonnance  with  acceptable 
forward-flight  and  endurance  performance.  These  design  features 
made  the  helicopter  the  only  design  yet  for  ship-borne  ASW 
missions  regarding  dipping  sonar.  Currently  only  conventional 
manned  designs  are  in  development  or  in  service  worldwide,  but 
unmanned  and  unconventional  designs  are  feasible  due  to  the 
availability  of  technology. 

•  Dipping  sonar:  The  major  acoustic  detection  device  for 
helicopters  is  the  dipping  sonar.  ASW  aerial  assets  should  today  be 
integrated  in  the  framework  of  network  centric  ASW.  That 
demands  modem  dipping  sonar  systems  which  have  centric 
frequency  and  bandwidth  and  are  compatible  with  surface  ships 
and  with  sonobuoys.  Helicopters,  equipped  with  dipping  sonar,  are 
considered  as  the  greatest  threat  to  submarines,  especially  in 
littoral  regions.  (Watts,  2005).  The  sonar  data  will  be  processed  by 
an  ASW  processing  computer  which  is  part  of  the  helicopter’s 
dipping  sonar  system.  That  means  many  ASW  helicopters  are  able 
to  process  and  manage  the  sonar  data  with  its  computers  and  crew. 
Nevertheless,  according  to  Jane’s  the  SH-60’s  LAMPS  MK  III 
ASW  system  is  not  a  fully  independent  operating  system;  rather  it 
relies  on  other  ASW  vessels  which  provide  computing  power  and 
personnel  to  process  and  evaluate  sonar  data.  Accordingly,  dipping 
sonar  data  could  be  processed  and  managed  by  ASW  ships  only, 
too. 

•  Sonobuoys:  These  buoys  are  used  by  vessels  and  helicopters  and 
are  considered  as  a  primary  airborne  detection  system.  They  are 
expendable,  relatively  cheap,  and  reliable  and  are  in  use  as  passive 
and  active  variants,  directional  and  non-directional,  large  and  small 
size.  Sonobuoys  transmit  their  sonar  data  to  the  aircraft  for 
processing  (Watts,  2005).  Accordingly,  the  sonar  data  could  also 
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be  solely  transmitted  from  the  aircraft  to  ships  for  further 
processing,  analyzing,  and  management. 

The  following  components  are  in  use  by  ASW  vessels  and  ASW  aerial 
systems.  Analyzing  the  multiple  components  used  should  enable  us  to  assess  which  of 
these  can  be  used  together  and  which  are  not  mandatory  for  a  single  aerial  ASW  system 
within  a  system  of  systems. 

•  Mission  data  processing  and  management  systems:  In  today’s 
weapon  systems  many  different  sensors  are  used,  and  the 
infonnation  and  data  collected  need  computerized  processing  to 
identify  and  filter  important  data,  to  organize  them  in  order  of 
importance,  and  to  distribute  them  between  the  different  users 
automatically  (management).  That  is  especially  true  for  aerial 
ASW  assets  which  have  the  most  sensor  density  on  board.  To  bring 
these  data  from  all  sensors  together  and  to  manage  these  by  crews 
requires  intensive  computer  hardware  performance,  complex 
software,  and  well-trained  personnel  at  the  consoles.  The  latest 
ASW  helicopter  developments,  such  as  the  MH90,  suffer  in 
particular  from  delays  caused  by  problems  with  the  complex 
mission  processing  hardware  and  software.  Their  mission 
computer  and  software  are  designed  so  that  these  ASW  helicopters 
and  their  crews  can  use  and  operate  ithe  sensors  independent  from 
other  assets.  Only  completely  processed  data  will  be  exchanged 
between  different  ASW  assets.  An  exception  to  this  model  is  the 
U.  S.  Navy’s  SH-60.  ASW  ships  have  many  more  resources 
available  in  respect  to  hardware  and  human  capital  to  process, 
analyze,  and  manage  sensor  data  than  any  helicopter  could  due  to 
size  and  weight  limitations.  A  conclusion  is  to  consider  the 
processing  capabilities  of  the  aerial  ASW  system  that  could  be 
reduced  and  simplified,  and  those  that  could  be  managed  by  the 
organic  ship  through  the  exchange  of  collected  basic  data  rather 
than  relying  on  independent  processing  perfonnance. 

•  Electronic  warfare  suite  (EWS):  EWS  detects  electronic 
emissions,  measures  their  amplitude,  and  analyzes  the  parameters 
so  that  the  transmissions  can  be  identified  against  a  stored  library 
of  emitters.  However,  within  a  littoral  area  where  a  submarine 
operates,  it  is  most  unlikely  that  any  hostile  submarine  would  emit 
any  transmissions.  Therefore,  EWS  is  not  a  primary  or  even 
secondary  sensor  for  ASW.  The  EWS  of  ships  is  more  powerful 
and  sensitive  than  those  of  most  aerial  ones;  nevertheless,  due  to 
the  closer  distance  to  the  threat  and  altitude  advantage  of  aerial 
systems,  EW  receivers  are  needed  at  least  for  aerial  ASW  assets 
when  conducting  ASW  missions.  Additionally,  ESW  is  required 
for  aerial  systems’  safe  operation  to  detect  other  surface  and  aerial 
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transmitters,  and  to  avoid  other  hostile  threats.  EW  row  data  can  be 
processed  by  the  helicopter  crew,  but  it  could  also  be  transmitted  to 
peer-systems  for  further  processing,  analyzing,  and  management. 

•  Electro-optical  and  infrared  sensor  (EO/IR):  EO/IR  is  a  system 
with  several  cameras  which  operate  in  different  ranges  of  the 
spectrum  of  light.  That  enables  the  crew  to  see  the  objects,  like 
submerged  submarines  or  snorkels,  through  magnification  during 
the  day  and  night.  Additionally,  the  IR  spectrum  allows  for  the 
detection  of  heat  signatures,  such  as  the  hot  air  exhausted  by 
submarines  when  diesel  engines  are  recharging  batteries,  during 
day,  night,  and  severe  weather.  The  EO/IR  sensors  are  often 
connected  to  the  radar,  which  enables  them  to  transfer  radar  track 
data  to  the  EO/IR  system  and  lock  on  a  radar  track.  Today’s  EO/IR 
systems  use  computer  software  to  process  the  picture  before 
displaying  it  to  the  crew  Once  more,  due  to  the  closer  distance  of 
the  threat  and  the  altitude  advantage  of  aerial  systems,  a  EO/IR 
sensor  is  required  for  aerial  ASW  assets  when  conducting  ASW 
missions.  When  helicopters  hover  to  dip  the  sonar  transducer,  their 
hover  altitude  exposes  them  to  the  threat  of  collisions  with  ships; 
thus,  an  EO/IR  sensor  is  also  useful  (although  not  required)  for 
aerial  systems  to  detect  other  surface  vessels  and  avoid  collisions 
during  the  night  or  severe  weather  conditions.  Although  EO/IR 
row  data  can  be  processed  by  the  helicopter  crew,  it  could  also  be 
transmitted  to  peer-systems  for  further  processing,  analyzing,  and 
management. 

•  Radios,  data  link,  and  de/encryption  devices:  The  transmitting 
systems  used  are  commonly  radios  capable  of  using  civil  and 
military  frequencies  in  the  HF,  VHF,  and  UHF  bandwidth. 
De/encryption  devices  are  also  commonly  used  by  allies  and 
NATO  for  radio,  voice,  or  data-only  secured  transmission.  Link 
systems  allow  for  two-way  transmission  of  data  via  radio 
automatically  as  well  as  to  feed  the  mission  system.  Thus,  aerial 
and  sea  vessels  need  these  systems  to  interoperate  with  other 
systems.  A  satellite-radio  capability  is  usually  not  required  for 
ASW  missions,  because  helicopters  operate  within  radio  distance 
of  ships. 

•  Radar:  Radar  is  one  of  the  most  important  sensors  for  on-sea 
operation  of  aerial  assets  because  no  air  traffic  control  exists  at  sea, 
and  the  aircraft  need  radar  for  collision  avoidance.  A  radar  system 
is  not  required  for  an  aerial  ASW  system  only  when  peer  systems 
provide  radar  control.  However,  the  system  cannot  leave  the  radar 
control  area.  That  may  cause  problems  when  the  system  is  radar- 
controlled  by  ships  and  when  the  system  is  at  low  altitude  (hover); 
The  earth’s  curvature  limits  the  radar  distance  for  ships  at  low 
altitude.  On  the  other  hand,  the  radar-distance  extension  provided 
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by  aerial  systems  is  also  vital  today  for  naval  ships.  To  conduct  an 
ASW  mission  successfully,  radar  is  very  important  to  detect 
surfaced  and  snorkeling  submarines  at  some  distance.  Thus,  a  radar 
system  is  in  principle  a  vital  system  of  any  naval  vessel  and  aerial 
asset. 

•  ASW  weapons:  The  primary  ASW  weapon  is  today  the  torpedo  in 
many  variants.  They  can  be  separated  into  heavyweight  and 
lightweight  torpedoes,  which  rely  on  different  kinds  of  energy 
sources  for  their  propulsion.  Due  to  weight  and  size  constraints, 
ASW  aircraft  use  only  lightweight  torpedoes.  These  variety  is  also 
often  used  by  ASW  capable  ships,  too. 
Other  ASW  weapons  are  guided  ASW  weapons  (torpedo  carrying 
missiles)  ASW  rockets  (including  rocket  boosted  torpedoes- 
ASROC),  bombs,  and  depth  charges.  Only  those  missiles  that  can 
be  deployed  by  surface  vessels  missiles  are  deployed  by  both  kinds 
of  assets.  Even  so,  a  submarine  will  never  operate  surfaced  within 
a  theater  of  war,  except  when  it  is  in  serious  trouble.  Thus,  the 
probability  of  engaging  a  surfaced  submarine  is  very  unlikely. 
Therefore,  primarily  torpedoes  and  secondarily  bombs  are  the 
weapons  of  choice  for  ASW  conducting  aircraft.  But  lightweight 
torpedoes  weigh  up  to  300  kg,  and  ASW  helicopters’  flight 
perfonnance  (particularly  their  hover  performance)  is  very  limited 
by  weight.  Especially  small  helicopters,  like  the  “Sea  Lynx,”  are 
not  capable  of  carrying  all  the  sensors  and  ASW  weapons 
simultaneously.  Against  this  background  the  German  Navy  used  to 
operate  two  “Sea  Lynx”  helicopters  in  parallel;  while  one  of  them 
carried  the  torpedoes  only,  the  other  conducted  the  search  with  the 
dipping  sonar.  Another  problem  is  that  unused  torpedoes  that  are 
deployed  on  helicopters  must  be  brought  back  to  the  ship.  These 
torpedoes  have  a  limited  life  before  they  require  maintenance 
(MTBM).  A  torpedo  requested  by  the  helicopter  and  deployed 
from  ship  with  a  range  that  covers  the  mission  area  of  the 
helicopter  would  enable  us  to  use  the  ASW  helicopter  without  the 
disadvantage  of  carrying  torpedoes.  That  would  increase  their 
flight  endurance. 

It  can  be  summarized  that  all  the  physical  components  discussed  in  this 
section  are  required  within  an  ASW  system  of  systems,  but  not  all  physical  components 
are  required  for  a  single  ASW  system.  With  respect  to  the  aerial  system  only,  it  can  be 
concluded  that  an  airframe,  dipping  sonar,  sonobuoys,  and  an  EO/IR  sensor  comprise  the 
minimum  elements  of  what  a  physical  design  should  contain  to  fulfill  requirements  and 
functions  within  an  ASW  system  of  systems.  On  the  other  hand,  the  aerial  system’s  need 
for  physical  components  related  to  mission  data  processing  capacity,  radar,  and  anti- 
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submarine  weapons  depends  on  the  users,  the  operational  concept,  and  how  deep  it  will 
be  embedded  in  an  ASW  system  of  systems. 

2.  System  Architecture  and  Basic  Design  Solutions 

The  knowledge  gained  from  the  functional  to  physical  architecture  and  the 
completed  analysis  enables  us  to  develop  alternative  designs.  The  first  could  focus  on  the 
design  of  a  single  ASW  system,  which  means  it  is  a  conventional  manned  ASW 
helicopter  that  fits  onto  the  various  ASW  ships  with  respect  to  its  physical  parameters. 
That  solution  contains  all  or  at  least  the  most  of  the  physical  components,  and  most  likely 
it  fulfills  the  required  functions.  However,  it  will  not  fulfill  the  requirement  for  endurance 
perfonnance.  That  solution  could  be  a  market  available  product.  Another  approach  could 
be  a  design  of  a  manned  helicopter,  but  its  mission  equipment  is  strictly  tailored  to  be  a 
system  of  systems  solution.  That  means,  it  does  not  fulfill  all  required  functions. 
Therefore,  it  must  cooperate  closely  with  its  organic  ASW  ship,  or  at  least  with  other 
ASW  peer  systems,  to  conduct  an  ASW  mission  successfully.  This  approach  could 
generate  more  endurance  because  the  helicopter  has  to  carry  fewer  components  and  can 
carry  more  fuel.  This  solution  is  not  market  available,  but  the  components  (including  the 
airframe)  are  available  individually.  Additionally,  this  design  approach  would  involve 
other  ASW  peer  systems;  in  particular,  it  involves  the  organic  ship  into  the  solution. 
When  this  solution  is  broken  down,  the  functions  and  physical  components  for  ASW  will 
be  distributed  across  several  aerial  systems,  as  is  already  practiced  by  the  German  Navy 
by  separating  sensors  on  weapons  and  two  “Sea  Lynx”  helicopters. 

To  achieve  increased  endurance  and  perfonnance  specially  tailored  designs  and 
system  solutions  are  necessary.  Today  unmanned  aerial  systems  (UAS)  must  be  taken 
into  consideration.  That  kind  of  aerial  vehicle  allows  for  specialization  with  respect  to  the 
design  that  more  strictly  adheres  to  the  requirements  and  functions.  Unmanned  aerial 
systems  cannot  operate  independently  because  they  have  no  crew  on  board,  and  more 
significantly  in  the  ASW  context,  the  UAS  is  a  system  of  systems.  This  possible  approach 
makes  ASW  peer  systems  and  the  organic  ASW  ships  part  of  the  solution.  Once  more, 


100 


such  a  solution  can  be  broken  down  even  further  when  the  functions  and  physical 
components  for  ASW  are  separated  and  distributed  on  several  aerial  systems. 

According  to  the  previously  analyzed  infonnation,  the  alternative  solutions  will 
propose  three  different  basic  design  approaches  to  cover  the  CPM’s  need  for  different 
solutions,  including  the  use  of  available  products,  improvement  of  in-service  materiel, 
and  realization  of  new  products,  and  the  need  to  fill  the  capbalitity  gap.  The  perfonnance 
requirements  concerning  the  sensor  performance  of  dipping  sonar,  sonobuyos,  radar  and 
EO/IR  shall  be  at  least  the  same  as  those  of  the  MH90.  In  this  ASW  case  it  is  assumed 
that  the  latter  requirement  is  set  by  the  stakeholders  and  decision  makers  as  a  common 
sensor  solution  to  simplify  the  process  and  keep  the  costs  and  risks  down.  Therefore,  all 
alternatives  will  be  equipped  with  the  same  sensors  and  weapons  or  at  least  with  sensors 
with  the  equivalent  performance.  In  this  ASW  case  that  limitation  and  preselection  of 
certain  sensors  and  weapons  simplifies  the  acquisition  process.  The  alternative’s  sensors 
and  weapons  will  include  the  following: 

•  Thales  Flash  dipping  sonar 

•  Selex  Seaspray  7000E  Radar 

•  Standard  helicopter  sonobuyo  dispenser 

•  Wescam  MX  15  EO/IR  turret, 

•  Link  11,  16,  and  22  system 

•  Eurotorp  MU90  impact  torpedo 
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a.  Available  Product  Solution 

The  first  possible  alternative  solution  could  be  an  AW  159  “Wild  Cat” 
“off  the  shelf’  solution  (Agusta  Westland,  2013). 


Figure  41.  AW  159  “Wild  Cat”  arts  image. 
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Figure  42.  List  of  physical  components  and  performance  of  the  AW  159  “Wild  Cat”  “off 

“the  shelf.” 


The  company  Agusta  Westland  developed  the  AW  159  “Wild  Cat”  in  an 
Army  and  Navy  version  based  on  a  contract  with  the  British  forces.  It  is  a  reengineered 
and  improved  evolutionary  design  and  still  bases  on  the  “Sea  Lynx”  helicopter,  which  is 
still  in  service  on  board  of  the  ASW  capable  frigates.  The  physical  size  and  shape  of  the 
AW  159  is  like  the  old  “Sea  Lynx.”  Thus,  the  interoperability  and  embarkment  of  the 
AW  159  on  the  F123  and  F124  is  given  and  should  not  be  a  concern.  The  helicopter  is 
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available  on  the  market,  and  no  developments  or  adaptions  are  required.  It  is  an 
independent  ASW  design  that  carries  all  sensors  and  components,  except  sonobuoys.  It 
also  carries  a  crew  to  process  and  manage  ASW  data,  and  to  deploy  its  torpedoes  or  depth 
charges.  Accordingly,  this  solution  needs  no  ASW  peer  systems  to  conduct  an  ASW 
mission,  but  it  can  also  operate  within  an  ASW  of  systems  due  to  its  radios  and  tactical 
data  link  capability. 


b.  Improvement  of  In-Service  Materiel 


A  second  possible  alternative  design  could  be  to  modernize  and  improve 
the  Mk  88A  “Sea  Lynx”  that  is  still  in  service.  The  airframe  still  has  enough  remaining 
flight  hours  left  before  the  life-cycle  ends.  Furthermore,  it  could  be  tailored  to  system-of- 
systems  ASW  operations  which  would  involve  adding  the  organic  ship  or  second  aerial 
system  into  the  solution: 


Figure  43.  German  Navy  Mk  88A  “Sea  Lynx.” 


This  possible  alternative  could  be  modernizing  and  refurbishing  the  Mk 
88A  “Sea  Lynx”  airframe,  electric,  and  engines  to  extend  the  life  cycle,  and  it  could  be 
equipped  with  new  sensors  similar  to  those  of  the  MH90.  Additionally,  it  could  be  taken 
into  consideration  that  the  mission  processing  system  and  the  third  crew  member  and  his 
console  could  be  removed  from  the  helicopter.  Weight  and  space  saving  should  enable  us 
to  equip  this  alternative  with  additional  internal  fuel  cells.  Accordingly,  the  endurance 
could  be  increased  to  a  level  close  to  that  of  the  MH90.  To  enable  this  alternative  design 
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to  conduct  ASW  missions,  the  sonar  data  must  be  transmitted,  processed,  and  managed 
by  crew  members  on  board  the  organic  ASW  ship.  That  means  that  this  alternative 
system  is  truly  a  system  of  systems  in  respect  to  the  organic  ship.  The  pilots  only  fly  the 
helicopter  according  to  dipping  positions  advised  by  ship’s  crew. 

c.  Realization  of  a  New  Product 

The  third  solution  would  include  an  unmanned  aerial  system.  Currently  no 
market-available  UAS  exists  that  can  conduct  dipping  sonar  missions.  The  United  States 
Anny  and  Navy  have  already  some  promising  helicopter  drone  systems  in  use,  or  in 
development,  but  they  do  not  yet  fulfill  the  requirements  of  the  ASW  need.  These  are  the 
K-Max  (Lockheed  Martin,  2013),  UAS,  A 160  Hummingbird  (Northrop  Grumman, 
2013a),  and  the  MQ-8C  Fire-X  (Northrop  Grumman,  2013b). 


Figure  44.  Lockheed  Martin  K-max  UAS. 
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Figure  45.  Northrop  Grumman  MQ-8C  Fire-X. 


Figure  46.  Boing  A  160  Humming  Bird. 


K-Max  and  Fire  Scout  are  already  deployment  proven  systems  and  have 
logged  several  thousand  operating  hours  The  Fire-X  will  start  at  a  low  rate  of  production 
and  initial  operational  with  the  U.S.  Navy  in  2014.  Except  for  the  A  160  Hummingbird, 
the  UAS  are  derived  from  manned  helicopters  which  are  intended  for  decades  in  service. 
These  systems’  operational  purpose  and  design  is  mainly  tailored  to 
transport/replenishment  purposes  and  intelligence,  surveillance,  and  reconnaissance  (ISR) 
missions.  All  three  systems  are  smaller  in  size  and  weight  than  the  “Sea  Lynx”  and  would 
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fit  onto  the  German  ASW  frigates.  All  these  systems  are  capable  of  conducting  flights  of 
between  at  least  5  and  up  to  12+  hours  with  some  payload.  Concerning  the  requirement  to 
deploy  a  dipping  sonar,  only  the  K-Max  and  MQ-8C  Fire-X  are  capable  of  carrying  the 
payload  of  a  dipping  sonar  (approx.  300  kg),  but  they  are  not  designed  to  accommodate  it 
internally;  so  they  would  need  a  major  redesign.  No  serious  data  are  available  concerning 
their  mission  endurance  when  conducting  a  typical  dipping  sonar  mission,  of  course, 
because  this  unique  flight  profile  with  many  and  long  hovers  has  not  been  flown  by  any 
UAS  yet.  The  current  endurance  of  the  Fire-X  of  1 1  hours  with  a  payload  of  600  lbs 
(max.  internal  1000  lbs)  promises  dipping  sonar  flight-profile  performances  which  are 
superior  to  every  current  available  and  manned  ASW  helicopter,  but  it  combines  this 
performance  with  a  lot  smaller  size  and  weight  footprint.  However,  even  when  none  of 
these  UAS  is  really  usable  for  dipping  sonar  missions,  these  UAS  demonstrate  the 
tremendous  endurance  increase  in  contrast  to  manned  ASW  helicopters  combined. 
Therefore,  they  represent  the  basic  technical  feasibility  of  naval  ship-borne  helicopter 
drones  and  the  expected  endurance  increase  for  a  sonar  dipping  system. 

d.  Complementary  Possible  Solution  for  all  Alternatives 

An  additional  solution  is  to  free  the  helicopter  from  its  torpedoes;  torpedo 
engagement  would  be  done  by  the  ships  themselves.  Usually  ships  are  out  of  range  to 
deploy  torpedoes  on  the  tracked  threat,  but  developments  such  as  “MILAS”  can  increase 
their  range  up  to  32nm.  “MILAS”  is  a  surface  launched  ASW-torpedo  carrying  missile 
system  and  uses  an  MU  90  torpedo  which  is  also  in  service  of  the  German  Navy. 
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Figure  48.  “MILAS”  system  components. 


e.  Summarizing  and  Assessing  the  Alternative  ’s  Features 

The  first  alternative  represents  a  typical  multi-role  helicopter  which  covers 
several  more  requirements  than  just  an  ASW.  The  disadvantage  of  this  design  is  that  it 
lacks  the  fuel  capacity  to  fulfill  demanding  endurance  requirements  like  those  of  the 
MH90  with  four  hours  ASW  endurance.  It  is  not  known  if  the  AW  159  can  perfonn  the 
maximum  endurance  with  full  ASW  equipment  and  torpedoes,  but  due  to  the  high  power 
performance  increase  over  its  predecessor,  we  can  assume  so.  Furthermore,  it  seems  that 
this  solution  is  not  capable  of  using  sonobuoys  and  dipping  sonar  in  parallel,  because  the 
available  room  in  cabin  is  not  sufficient  to  accommodate  both  sensors  at  once.  The  IPT 
has  to  release  a  request  for  information  (RFI)  from  the  producer  to  get  more  detailed 
information  regarding  performance,  functionalities,  technical  design  features,  and  basic 
costs.  This  solution  approach  would  satisfy  the  CPM’s  request  for  identifying  and 
assessing  of  available  products.  This  solution  also  promises  an  immediately  available 
product  and  a  low  risk  related  to  schedule  and  funding  because  there  is  no  need  for  any 
development.  Even  less  integration  is  required  if  ordered  “off  the  shelf,”  but  this  solution 
may  not  meet  all  requirements.  It  depends  on  the  KPPs  and  the  decision  makers  whether 
this  alternative  can  stay  in  the  selection  process,  or  if  it  must  be  eliminated  due  to  missing 
the  minimum  requirements  to  fill  the  capability  gap. 

The  second  alternative  solution  would  include  the  organic  ASW  ship  in 
the  development  and  procurement  process  for  ASW  weaponry  and  sonar  data  processing 
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and  management  systems.  However,  in  contrast  to  the  first  alternative,  it  could  increase 
mission  endurance  significantly.  This  approach  would  satisfy  CPM’s  need  for  assessing 
in-service  materiel.  The  IPT  must  also  release  RFIs  to  all  concerned  producers  of  the 
helicopter,  missile,  and  the  ships  to  gain  information  and  data  for  further  assessment 
processes.  Furthermore,  this  solution  approach  needs  research  and  technology  (R&T)  that 
also  involves  modeling,  simulation,  and  prototyping  to  evaluate  technical  feasibility  in 
respect  to  helicopter  modification.  That  solution  promises  a  medium-term  available 
product. 

The  third  alternative  represents  a  solution  which  concerns  a  new  product 
and  realization  regarding  the  aerial  vehicle  and  the  systems  on  board  the  organic  ships. 
This  solution  requires  the  most  intensive  R&T  process  including  modeling,  simulation, 
and,  in  particular,  prototyping  of  the  aerial  system  and  the  ground  system  on  board  the 
ships.  Depending  on  the  technical  feasibility  a  UAS  could  fulfill  or  even  exceed  the 
endurance  requirements,  and  most  likely  it  can  carry  all  needed  ASW  sensors  and 
weapons  at  once.  This  third  solution  would  also  heavily  involve  the  organic  ship  in  the 
system  development  and  design  process,  because  the  UAS  has  to  be  accommodated, 
maintained,  controlled,  and  operated  on  board  the  ship  by  its  crew.  Most  likely  many 
other  hardware  and  software  changes  need  to  be  done  also  to  establish  line  of  sight  (LOS) 
connectivity  for  VHF/UHF  radios  in  order  to  integrate  this  solution  successfully  into  the 
existing  ASW  ships.  Therefore,  in  tenns  of  time  requirements  and  R&T  funding  concerns 
this  is  the  most  challenging  of  the  three  basic  solutions.  On  the  other  hand,  it  promises  the 
best  perfonnance  potential  and  maybe  the  greatest  cost  savings  over  the  life  cycle,  as  the 
K-Max  UAS  has  already  impressively  proved  in  Afghanistan  (Price,  2013).  The  third 
solution  has  only  long-tenn  availability  and  has  most  likely  the  highest  level  of  high  risk 
concerning  technical  feasibility,  schedule,  and  funding  because  of  the  need  for  complete 
development  and  full  integration  of  the  drone  with  ground  control  and  operation 
management  on  the  different  ships.  Even  so,  it  promises  the  highest  grade  of  fulfillment 
concerning  the  requirements  and  perhaps  the  lowest  life-cycle  cost  as  well. 

All  three  alternatives  promise  a  possible  solution.  Every  one,  of  course, 
promises  a  different  cost,  schedule,  and  performance,  which  are  called  triple  constraints 
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in  military  program  management  and  reflect  the  program  manager’s  basic  goals.  Further 
steps  of  the  process  of  preparation  for  decision  making  will  help  to  measure  and  evaluate 
each  alternative  with  respect  to  the  triple  constraints. 

An  additional  solution,  which  supports  all  three  aerial  solutions,  is  the 
“MILAS”  system  that  would  at  least  benefit  all  three  solutions.  It  is  independent  from  the 
aerial  system  and  allows  us  to  free  the  helicopters  from  the  torpedoes  (weight)  when 
operating  within  a  30  nm  radius  of  the  ship.  The  30  nm  radius  screen  is  a  typical  ASW 
scenario  (Figure  49)  to  protect  carrier  strike  groups  (CSG)  with  ASW  helicopters  (NPS 
capstone  project,  NPS-SE-08-002,  2008).  The  same  is  perhaps  true  with  respect  to 
shifting  the  mission  data  processing  and  management  components  and  crews  from  the 
helicopter  to  the  ships.  In  particular  when  the  aerial  ASW  systems  operate  within  line  of 
sight  (UHF/VHF)  to  the  organic  ship,  which  is  what  happens  usually  when  conducting 
ASW  escort  missions.  In  this  situation,  data  transmission  is  not  a  technical  and  security 
issue,  and  it  has  already  been  applied  this  way  by  NATO  navies  for  decades  using  the 
naval  Link  1 1  and  Link  22  components  on  ships  and  aircraft. 


Figure  49.  Helicopter  coverage  area  according  to  NPS  capstone  project  [NPS-SE-08-002, 

2008]. 


The  systems  engineering  design  process  applied  so  far  has  enabled  us  to 
identify  the  functions  and  physical  components  and  their  allocation  within  an  ASW 
system  of  systems.  It  is  true  that  an  aerial  ASW  system  does  not  need  all  functions  and 
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physical  components  combined  into  one  system  as  is  currently  the  case  with  ASW 
helicopters  like  the  MH90  and  SH-60R.  The  ASW  system  can  also  consist  of  several 
systems  which  operate  in  a  system  of  systems.  The  IPT  should  take  the  newly  gained 
knowledge  into  consideration  and  should  separate,  regarding  the  CPM’s  analyzing 
process,  the  “MILAS”  and  the  mission  data  processing  and  management  system  from  the 
original  ASW  need  process.  Both  systems  are  ships  systems  and  should  be  researched 
and  analyzed  by  another  “ship”-IPT  that  should  work  parallel  to  the  original  ASW-IPT. 
However,  the  ASW-IPT  should  proceed  with  all  three  possible  aerial  solutions. 

3.  Detailed  Design  of  the  Alternative  Solutions 

a.  Introduction 

Refining  the  requirements,  basic  work  breakdown  structures  (WBS), 
specifications,  and  measures  of  perfonnance  need  to  be  detennined  to  enable  the  IPT  to 
develop  further  the  alternative  solutions  and  to  understand  their  functions  and  physical 
architecture.  Subsequently,  it  will  enable  the  IPT  to  task  contractors  to  conduct  studies, 
research,  modeling,  and  simulation  on  the  possible  solutions  to  get  more  infonnation 
about  the  technical  feasibility  and  technology  readiness  level  (TRL)  of  each  alternative.  It 
is  required  to  provide  the  contractor  with  a  comprehensive  and  sound  request  consisting 
of  accurate  and  well-written  specifications,  as  well  as  limited  scenarios  and  test  cases  to 
support  the  contractor’s  understanding  about  their  task  if  useful  results  are  expected.  The 
first  alternative  is  already  available  “off  the  shelf,”  and  therefore,  it  will  not  be  discussed 
further  in  this  thesis.  The  same  is  valid  for  the  second  alternative.  Therefore,  the 
remainder  of  this  thesis  will  focus  on  the  third  alternative  to  proceed  with  the  application 
of  systems  engineering  methodologies  and  tools. 

b.  Work  Breakdown  Structure 

The  WBS  illustrates  all  basic  physical  components  on  all  levels  to  produce 

a  system  and  how  to  integrate  the  components  on  each  WBS-level  of  the  system.  Because 

a  WBS  captures  the  work  necessary  to  develop  and  produce  a  system,  according  to  Allen 

(2008),  it  is  an  excellent  tool  to  support  most  activities  within  project  work.  The  MIL- 

HDBK-881A  (Under  Secretary  of  Defense  (AT&L),  2005)  delivers  an  already  allocated 
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WBS  for  different  weapon  systems.  The  following  WBS  depicts  the  structure  for  a  UAS 
from  level  one  down  to  four  (Figure  50).  For  practical  reasons  only  the  UA  vehicle  and 
communication  are  broken  down  even  further.  The  WBS  should  be  done,  of  course,  for 
all  components  on  all  levels,  and  as  deep  as  necessary  for  the  work. 


Figure  50.  Work  Breakdown  structure  for  a  UAS  according  to  MIL-HDBK-88 1 A  [Under 

Secretary  of  Defense  (AT&L),  2005]. 


c.  Developing  Systems  Specifications  and  Test  Cases 

Requirements  are  insufficient  for  designing  a  solution  to  the  problem,  and 
must  be  translated  into  specifications  that  can  be  tested  or  verified.  It  is  difficult  to  get 
sound  requirements  definitions  and  specifications.  The  reasons  for  this  are  lack  of 
specification  language,  incorrect  interpretation  of  user  needs,  partial  knowledge  of 
questions  that  need  to  be  answered,  failure  to  recognize  the  critical  importance  of 
requirements  analysis,  and  unwillingness  to  spend  the  time  and  funding  to  get 
requirements  correct  at  the  first  time. 

Two  kinds  of  specifications  are  commonly  used  in  military  acquisition.  A 

performance  specification  defines  the  functional  requirements  for  the  system  and  it  shall 
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state  the  requirements  in  terms  of  the  required  verifiable  results,  but  without  stating 
methods  for  achieving  the  required  results.  Performance  specifications  should  be 
preferred  if  feasible  because  they  state  specifics  only  to  the  extent  necessary  for  interface, 
interoperability,  and  environment  in  which  the  system  or  its  component  must  operate. 
Perfonnance  specifications  usually  reduce  acquisition  costs,  take  advantage  of  new 
technology,  reduce  lead  time,  and  place  design  responsibility  on  the  contractor. 

By  contrast,  a  detailed  specification  gives  design  solutions,  such  as  how  a 
requirement  is  to  be  achieved  or  how  an  item  is  to  be  fabricated  or  constructed. 
Therefore,  detailed  specifications  specify  physical  characteristics  and  should  only  be  used 
if  necessary,  for  example,  to  define  certain  interfaces  between  components  or  systems. 

To  develop  sound  specifications  no  single  person  has  all  the  infonnation 
needed  to  lay  out  the  system.  It  is  again  a  team  effort  of  the  IPT  and  the  users  of  the 
system  to  specify  the  requirements.  The  Software  Engineering  Institute  (SEI)  of  the 
Carnegie  Mellon  University  in  Pittsburgh  (USA)  developed  the  Architectural  Tradeoff 
Analysis  Methodology  (ATAM)  for  software  projects  (Software  Engineering  Institute 
(2013).  However,  it  is  also  applicable  on  non-software  systems  and  an  effective  way  to 
develop  specifications  based  on  scenarios  concerning  function  and  component.  The 
following  figure  (Figure  51)  retrieved  from  Prof.  Naegle’s  software  acquisition  class  at 
the  Naval  Postgraduate  School  (NPS)  shows  the  basic  relationships  involved  and  the 
methods  used  to  develop  from  the  need  scenarios  for  use  case,  growth  and  exploratory 
scenarios,  and  finally  to  develop  test  cases  to  measure  and  evaluate  the  specified 
scenario.  (In  Figure  51,  MUIRS  stands  for  maintainability,  upgradeability, 
interoperability,  reliability,  and  security/safety,  and  FMECA  stands  for  failure  mode, 
effects  and  criticality  analysis.) 
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Figure  51. 


Example  of  basic  application  of  SEI-ATAM  according  to  Naegle  (2013). 


Figure  52  illustrates  how  the  requirement  of  interoperability  with  regard  to 
the  DDCU  on  WBS  level  four  can  be  developed  into  a  performance  specification  related 
to  scenarios  and,  subsequently,  into  test  cases.  This  step  should  be  applied  for  the  whole 
WBS  and  be  broken  down  as  far  as  necessary  to  cover  all  requirements  and  functions  in 
respect  to  the  components  and  their  specifications  and  test  cases. 


Use  Case  Scenario:  Reliability 

During  a  ASW  mission  the  correct  and  proper 
processing  von  mission  data  coming  from  external 
assetes  like  ships,  airplanes  and  ground  control  must 
be  achieved  that  the  UAV  can  conduct  its  ASW 
mission  in  cooperation  with  other  assets.  Therefore, 
when  the  system  is  in  operational  flight  to  conduct  a 
mission,  all  internal  and  from  external  incoming  data 
from  Link  11/16/22  IFF  and  flight  control  data  must 
be  processed  and  distrubuted  by  the  DDCU  to  the 
other  system  components  simultaneously  with  a 
ireliabilit^of0|i999j^^^^^^_^_^^^^_ii____ 


Test  Case:  Use  Case  Scenario  Reliability 

Conduct  a  DT&E  on  a  system  components  laboratory 
test-rack  to  enable  the  simulated  use  of  all 
componets  simultaneously  over  a  predetermined 
certain  time  to  proof  the  demanded  reliability  of  the 
DDCU. 

Conduct  OT&E  on  a  LRIP  system  to  proof  succesful 
operation  of  the  DDCU  in  flight. 
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Figure  52.  Application  of  ATAM  concerning  the  ASW  UAS. 

Many  other  ways  of  developing  sound  specifications  and  test  cases  exist. 
The  method  examined  here  is  just  one  way,  but  a  very  effective  one  because  the 
specifications  and  test  cases  are  derived  from  case  scenarios.  As  such,  they  help  us  to 
understand  the  specifications,  and  therefore,  they  are  easily  replicated. 

4.  Analysis  of  Alternatives  (AoA) 
a.  Introduction 

The  U.S.  Defense  Acquisition  Guidebook  (Under  Secretary  of  Defense 
(AT&L),  2011)  states  the  analysis  of  alternatives  is  an  important  element  of  defense  and 
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procurement  processes  which  play  a  key  role  in  support  of  the  materiel  solution  analysis 
phase.  It  is  described  as  an  analytical  comparison  of  the  operational  effectiveness, 
suitability,  and  life-cycle  cost  (or  total  ownership  cost)  of  alternatives  that  satisfy 
reasoned  capability  needs,  as  shown  in  Figure  53. 


Figure  53.  Determination  factors  of  a  system’s  total  value  [Blanchard,  Fabrycky,  2011]. 

The  goal  of  AoA  is  to  examine  potential  materiel  solutions  and  in  a  second 
step  to  identify  the  most  promising  option.  To  identify  the  most  promising  option,  as 
stated  in  the  guidebook,  does  not  mean  to  identify  only  the  best  and  most  effective 
solution,  rather  it  means  to  identify  the  most  promising  solution  in  respect  to  many 
factors,  like  political  and  economic,  and  cost  and  strategic  constraints  as  illustrated  in 
Figure  54.  Therefore,  it  is  very  important  to  understand  that  even  the  same  solutions 
would  be  assessed  differently  if  different  nations  do  the  AoA  process,  due  to  their 
different  constraints.  Once  more,  an  AoA  process  is  not  the  only  way  to  conducting  this 
analysis.  Thus,  the  AoA  processes  vary  somewhat  for  weapon  and  other  tactical  systems 
and  need  to  be  adapted  to  each  program.  In  respect  to  systems  engineering,  risk 
management,  effectiveness  measure,  effectiveness  analysis,  cost  analysis,  cost 
effectiveness  comparison  and  presenting  and  assessment  of  the  results  are  the  steps  which 


115 


need  to  be  done  to  be  able  to  present  a  final  report.  This  true  for  the  CPM’s  second  part  of 
analysis  phase,  too. 

The  U.S.  Defense  Acquisition  Guidebook  (2011)  explains  the  role  of  the 
AoA  as  follows: 

The  AoA  is  used  to  identify  the  most  promising  end-state  materiel 
solution,  but  the  AoA  also  can  play  a  supporting  role  in  crafting  a  cost- 
effective  and  balanced  evolutionary  acquisition  strategy.  The  alternatives 
considered  in  the  AoA  may  include  alternative  evolutionary  paths,  each  path 
consisting  of  intermediate  nodes  leading  to  the  proposed  end-state  solution.  In 
this  way,  the  Materiel  Solution  Analysis  can  help  detennine  the  best  path  to 
the  end-state  solution,  based  on  a  balanced  assessment  of  technology  maturity 

and  risk,  and  cost,  perfonnance,  and  schedule  considerations - .  The  rationale 

for  the  proposed  evolutionary  acquisition  strategy  would  be  documented  as 
part  of  the  Technology  Development  Strategy. 
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Materiel  Solution  Analysis  and 
Technology  Development  Strategy 


Figure  54.  Establishment  of  an  evolutionary  acquisition  strategy  according  to  the  guidebook. 


b.  Evaluation  Measure 

Evaluation  measures  are  a  necessary  step  before  requirements  will  be 
defined.  With  regard  to  military  acquisition  processes,  especially  during  the  early  FFF- 
phase,  it  may  not  seem  very  applicable.  Therefore,  evaluations  measures  can  also  be  used 
to  verify  and  improve  or  even  correct  the  early  requirements  because  they  contain 
performance  and  quality  definitions. 

In  AoA,  evaluation  measures  help  to  verify  and  validate  the  studies, 
research  efforts,  delivered  detailed  information,  and  data  with  respect  to  the  most 
important  KPPs.  Evaluation  measurement  is  accomplished  using  a  quantifiable  form  with 
a  clear  definition  of  the  measure  and  the  units  associated  with  it,  and  should  focus  on 
what  is  important  objectively  (Figure  55).  Later,  during  the  analysis  of  alternatives 
process,  they  are  used  to  measure  the  level  of  success  of  alternatives  with  respect  to  the 
requirements  and  cost. 
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Figure  55.  Determination  factors  of  a  system’s  total  value  [Blanchard,  Fabrycky,  2011]. 

Measures  of  performance  must  be  related  to  the  requirements  stated  earlier 
and  to  KPPs.  The  ATAM  process  enables  us  to  develop  traceable  measures  of 
performance  for  each  alternative  component.  Testing  enables  us  to  deliver  results  of 
performance  measurement  for  validation  and  verification,  and  it  should  be  conducted 
throughout  an  acquisition  process.  The  performance  measurements  can  later  be  used  for 
the  measure  of  effectiveness. 

Figure  56  illustrates  the  path  from  requirement,  which  is  converted  to  a 
physical  component  according  to  the  WBS,  down  to  the  sub-component  and  to  its 
specification  and  test  cases  which  delivers  the  measured  performance. 
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Figure  56.  The  path  from  requirement  and  physical  component  to  perfonnance. 

An  attribute  of  evaluation  measures  should  be  traceability  from  technical 
performance  measure  (TPM),  to  measure  of  performance  (MOP),  and  finally  to  the 
measure  of  effectiveness  (MOE)  of  the  alternatives.  Figure  57  (which  originated  in  Prof. 
Miller’s  Systems  Engineering  class  at  NPS)  shows  the  path  from  technical  performance 
measurement  up  to  measure  of  performance  and  at  least  to  the  measure  of  effectiveness 
(MOE). 
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Figure  57.  Evaluation  measures  and  traceability  according  to  Miller  (2012). 


Evaluation  measurement  quantifies  the  performance  for  each  capability  of 
the  components  and  the  system  as  a  whole,  and  the  value  functions  define  the  value  of 
each  evaluation  measurement  row  data’s  score.  The  way  to  measure  the  effectiveness  is 
to  get  raw  data  from  the  measure  of  performance  and  to  transform  them  into  values.  It 
depends  on  the  decisison  makers  how  the  values  will  be  weighted.  According  to  the 
preferences  of  the  decision  makers  the  value  functions  can  be  linear,  convex,  or  concave 
as  is  shown  in  Figure  58. 


Requirement  “x” 


%  capability  to  fulfill  requirement 


Linear  value  function: 
Equal  returns  to  scale 


Convex  value  function: 
Increasing  returns  to  scale 


Concave  value  function: 
Decreasing  returns  to  scale 


Figure  58.  Different  kinds  of  value  functions. 


The  values  of  each  evaluation  measure  need  to  be  put  into  a  table  and 
weighted  with  the  decision  maker’s  weights  in  respect  to  the  importance  of  each 
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evaluation  measure.  Each  alternative’s  total  value  score  is  calculated  by  multiplying  the 
values  with  the  weight  and  adding  them.  The  following  numbers  shown  in  Table  5  are 
random  numbers  used  for  explanation  and  might  apply  to  the  proposed  alternatives. 


Evaluation  Measure 

Global  Weight 

Alternative  1 

Alternative  2 

Alternative  3 

Maintenance 

0,15 

65 

58 

85 

Embarkation  capability 

0,2 

92 

92 

80 

Endurance  dipping  sonar 

0,25 

30 

50 

90 

Endurance  patrol 

0,05 

30 

60 

100 

Environment  capability 

0,15 

100 

100 

70 

Network  capability 

0,2 

65 

85 

90 

Total  Value  Score 

1,00 

65.15 

74.6 

84.75 

Table  5.  Basic  performance  total  value  score  matrix. 

The  third  alternative  solution  shows  the  highest  score  with  respect  to  the 
measures  and  weights.  The  score  reflects  the  effectiveness  related  to  the  measures. 
Effectiveness  is  defined  by  the  inputs  of  the  operational  scenarios,  requirements,  the 
alternative  system’s  attributes,  like  perfonnance,  and  the  preference  inputs  of  the  decision 
makers  as  depicted  in  Figure  59.  The  measures  used  in  the  result  or  decision  matrix 
covers  truly  not  all  relevant  issues  concerning  the  ASW  need.  It  just  give  the  level  of 
perfomance  to  some  requirements.  Many  more  requirements  and  even  more  operational 
ASW  scenarios  exist. 

Another,  much  more  comprehensive  and  spohisticated  way  to  get  results 
and  detennine  a  system’s  effectivenss  is  by  conducting  operations  research  (OR)  methods 
originated  during  World  War  II  as  a  response  to  tactical  problems  relating  to  the  efficient 
operation  of  weapon  systems,  and  to  operational  problems.  Today,  mission  effectiveness 
can  be  best  determined  through  conducting  OR  methods  because  it  ties  functions  and 
capabilities  together  with  mission  effectiveness. 
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Figure  59.  Input  flow  diagram  concerning  effectiveness  according  to  Hansen  (2012). 

According  to  Hansen  (in  Cost  Benefit  Analysis  class  at  NPS,  2012)  OR 
has  evolved  since  then  to  a  full-scale  scientific  discipline  that  is  practiced  widely  by 
analysts  in  industry,  government  and  the  military.  OR  is  a  development  and  application 
of  mathematical  models,  statistical  analyses,  simulations,  analytical  reasoning  and 
common  sense  to  the  understanding  and  improvement  of  real-world  operations. 
Improvement  can  be  measured  by  the  minimization  of  cost,  maximization  of  efficiency, 
or  optimization  of  other  relevant  measures  of  effectiveness. 

The  military  uses  OR  at  the  strategic,  operational  and  tactical  levels.  OR 
improves  decision  making  and  facilitates  insights  into  the  phenomena  of  combat.  OR 
applications  cover  military  activities  including:  national  policy  analysis,  resource 
allocation,  force  composition  and  modernization,  logistics,  human  resources,  battle 
planning,  flight  operations  scheduling,  intelligence,  command  and  control,  weapon 
selection  (weapon  system  effectiveness,  cost,  compatibility  and  operability),  engagement 
tactics,  maintenance  and  replenishment,  and  search  and  rescue  (NPS,  Department  of 
Operations  Research,  2013). 

With  respect  to  the  ASW  need,  OR  can  research  the  alternative’s 
performances  against  certain  scenarios  by  using  mathematical  modeling  and  in  a  later 
step  by  programming  software  and  conducting  simulations.  Accordingly,  OR  requires  all 
parameters  concerning  the  operational  concept  and  some  specific  operational  scenarios. 
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Furthermore,  performance  parameters  of  the  different  airframes,  sensors,  and  weapons 
are  required  to  develop  and  program  models  of  each  alternative.  The  needed  data  for 
operational  scenarios  should  be  available,  because  they  already  developed  und  delivered 
by  the  users  during  earlier  process  steps. 

The  data  concerning  alternative  one  and  two  can  be  requested  from  the 
producer,  but  alternative  three  has  not  yet  any  producer.  Logistic  data,  like  availability, 
concerning  alternative  two  are  available  because  it  is  service  and  data  can  be  requested 
from  the  Materiel  Command.  Concerning  alternative  three  data  from  related  projects, 
other  UAS,  studies,  and  technical  research  should  the  IPT  enable  to  deliver  some  value 
data  for  an  operational  research.  The  alternative’s  sensors  are  all  the  same  because  they 
are  set  by  stakeholders  and  decision  makers  as  common  sensor  solution.  Therefore,  the 
operational  research  has  to  focus  on  the  mission  effectiveness  in  respect  to  the 
performance  like  endurance,  numbers  of  possible  dipping  cycles,  availability,  and 
deployment  of  weapons.  It  must  be  acknowledged,  that  conducting  a  comprehensive 
operational  research  is  not  what  an  IPT  can  perfonn  rather,  it  must  be  ordered  to  an 
specialized  military  department  or  civil  contractor  must  be  tasked.  OR  contains 
methodologies,  which  requires  special  skills  and  knowledge  which  can  be  only  properly 
applied  by  OR-educated,  specialized  and  trained  personnel.  Accordingly,  an  operational 
study  on  the  ASW-need  could  easily  extend  to  a  thesis  itself  and  can,  therefore,  not  be 
covered  in  this  thesis. 


c.  Life-Cycle  Costs  for  the  Alternatives 

The  fundamentals  of  life-cycle  cost  (LCC)  are  already  described  in 
Chapter  IV  with  respect  to  the  basic  ASW-need  system  for  the  FFF-document.  The  LCC 
analysis  in  the  FFF-document  is  based  mainly  on  conceptual  design  with  little  actual  data 
available.  The  analysts  use  past  experience  and  intuition  to  make  rough  estimates  to 
support  a  top-level  design  decision.  By  contrast,  the  detennination  of  the  life-cycle  costs 
related  to  the  three  proposed  alternatives  cannot  be  based  on  estimations  only.  To  get  a 
cost  related  perfonnance  comparison  for  the  AoA  process  by  applying  a  cost-benefit 
analysis  (CBA),  the  costs  of  each  alternative  solution  with  respect  to  its  life-cycle  must 
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be  conducted  in  advance.  Life-cycle  cost  is  composed  of  many  different  factors.  These 
factors  are  illustrated  in  Figure  60.  The  number  of  factors  shown  enables  us  to  estimate 
the  vast  pile  of  work  “just”  to  detennine  a  system’s  total  cost.  Therefore,  this  task  is  more 
a  study  on  it  its  own  which  could  be  covered  by  a  single  thesis  or  capstone  project.  Thus, 
this  thesis  will  not  conduct  LCC  research  and  calculations  because  no  real  data  are 
available,  and  it  would  be  out  of  the  intended  scope.  However,  a  basic  discussion 
regarding  LCC  will  be  presented. 
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System/production  life-cycle 
management  (Crm) 

•  Project  management 

•  Production  management 

•  Logistics  support  management 

■  Product  planning  (CRP) 

•  Market  analysis 

•  Feasibility  studies 

•  Program  planning 

■  Product  research  (CRR) 

•  Applied  research 

•  Research  laboratories 

■  Engineering  design  (CRE) 

•  System  engineering 

•  Conceptual  design 

•  Preliminary  design 


•  Detailed  design 

•  Design  support 

•  Design  review 


Industrial  engineering  and 
operations  analysis  (Cpj) 

•  Plant  engineering  (CPiP) 

•  Manufacturing  engineering  (CPjm) 

•  Methods  engineering  (CPje) 

•  Production  control  (CPic) 

•  Sustaining  engineering  (CP|s) 

■  Manufacturing  <CPM) 

•  Tooling/test  equipment 

•  Fabrication 

•  Material  (inventories) 

•  Subassembly/assembly 

•  Inspection  and  test 

•  Packing  and  shipping 

•  Manufacturing  rework 

■  Construction  (Cpc) 

•  Manufacturing  facilities  (CpcP) 

•  Test  facilities  (Cpce) 

•  Consumer  operational  facilities 
(Cpcc) 

•  Maintenance  facilities  (Cprsi) 

•  Training  facilities  (Cpcr) 

•  Inventory  warehouses  (Crew) 

■  Quality  control  (CPq) 


System/product 
operations  (Coo) 

•  Operating  personnel  (Coop) 

•  Operator  training  (Cqot) 

•  Operational  facilities  (C0of) 

System/product 
distribution  (C0t>) 

•  Marketing  and  sales 

•  Transportation/traffic 

management _ 

Sustaining  logistics 
support  (Cql) _ 

•  Customer  service — life- 
cycle  support  (Colc) 

•  Warehouse  facilities  (Colw) 

•  Maintenance  facilities  and 
training  facilities  (Colm) 

•  Supply  support — spares  and 
inventoiy  support  (Cols) 

•  Maintenance  personnel 
training  (Colt) 

•  Test  and  support  equipment 
(Cole) 

•  Transportation  and  handling 
(Colh) 

•  Technical  data  (Cold) 

•  SystenVproduct 
modifications  (Cqlk) 


Disposal  of  nonrepairable 
system/product  elements 


System/product  ultimate 
retirement 
’  Logistics  support 
requirements — 
personnel,  support 
equipment,  transportation 
and  handling,  facilities, 
and  data 


•  Test  and  evaluation  ’  Supply  support— initial 

spares  and  inventory  (Cpts) 

•  Test  and  support  equipment 
(CPlt) 

•  Transportation  and  handling 
(Cplh) 

•  Technical  data  (CPu>) 

•  Personnel  and  training  (CPu») 

•  Training  and  equipment  (CPls) 


Figure  60.  A  general  cost  breakdown  structure  (CBS)  [Blanchard,  Fabrycky,  2011]. 


Blanchard  and  Fabrycky  (2011)  explain  that  LCC  analysis  needs  an 
analyst  with  a  thorough  understanding  of  the  LCC  process  and  who  has  some  knowledge 
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of  how  the  system  will  be  operated  and  maintained  by  the  user,  and  also  an  understanding 
of  the  major  interrelationships  between  activities  and  costs.  As  the  program  progresses 
and  a  more  specific  definition  of  the  system  emerges,  then  LCC  analysis  can  be 
accomplished  in  greater  depth.  Even  so,  the  LCC  analysis  relies  heavily  on  estimation 
which  is  based  on  the  experience  of  the  analyst.  Furthermore,  they  state  that  due  to 
increasing  data-input  requirements  the  LCC  analysis  becomes  more  complex.  That  may 
apply  especially  for  our  first  two  alternative  solutions  because  of  their  already  existing 
system  configurations  in  use.  It  may  be  appropriate  to  solicit  LCC  data  from  diverse 
sources  from  the  producer  and  other  involved  companies,  for  example,  for  maintenance, 
and  from  different  departments  within  the  German  Anned  Forces  which  have  cost  data 
related  to  the  system.  Analyzing  production  cost  is  usually  a  task  that  should  be  done  by 
the  producer.  However,  the  LCC  analyst  of  the  IPT  should  be  able  to  understand, 
validate,  and  assess  these  numbers  to  implement  them  correctly  in  the  LCC  analysis. 


Operation  RDTE 


Figure  61.  Example  of  shares  of  cost  factors  regarding  total  system  costs  [tms.org,  2013]. 

Up  to  50%  of  the  total  life-cycle  cost  can  be  caused  due  to  research, 
development,  test  and  evaluation  of  a  new  system  as  shown  in  Figure  61,  but  meanwhile 
the  share  of  operation  and  support  (O&S)  cost  of  new  weapon  systems  will  increase  more 
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and  more  in  relation  to  the  total  costs.  The  JSF  program  is  an  example  of  increasing  O&S 
costs.  Figure  62  shows  the  increase  of  estimated  O&S  costs  over  the  last  decade  in 
comparison  to  the  acquisition  costs. 


iSF  Estimated  Acquisitions  and  Operations  &  Support  Costs  (Billions) 
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Figure  62.  Estimates  of  acquisition  and  O&S  cost  of  the  JSF  program  from  2010  [mca- 

marines.org,  2013]. 

The  LCC  analysts  of  the  IPT  should  seriously  care  about  the  O&S  costs. 
In  the  beginning  of  a  program  these  costs  are  often  highly  underestimated,  as  Figure  62 
shows.  A  reason  to  underestimate  O&S  costs  may  be  the  high  involvement  of  software 
related  components  in  a  new  system.  Such  an  example  is  the  F-22  Raptor  for  which 
approximately  85%  of  all  functionality  is  software  driven  (Naegle,  2013).  Therefore,  a 
major  driver  of  increased  O&S  costs  today  is  the  complex  software  of  the  weapon 
systems,  which  can  account  for  up  to  40%  of  the  overall  O&S  costs  depending  on  the 
complexity  of  the  weapon  system.  The  cost  to  maintain  software  today  is  typically 
between  60%  and  80%  of  the  software  component  total  life-cycle  cost  because  software 
maintenance  is  personnel  intensive  (Naegle,  2013).  Many  old  weapon  systems  do  not 
have  this  software  complexity  and  cost  intensive  maintenance.  Accordingly,  their  cost- 
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data  does  not  reflect  much  data  concerning  software.  That  might  be  one  of  the  reasons 
that  experienced  LCC  analysts  currently  underestimate  O&S  costs. 

Another  major  driver  of  O&S  costs  is  the  required  availability  of  the 
system.  Operational  availability  (Ao)  is  defined  as  follows: 

uptime  MTBM 

Ao  =  -  =  - 

uptime  +  downtime  MTBM  +  MDT 

•  MTBM  (Mean  Time  between  Maintenance) 

•  MDT  (Maintenance  Down  Time) 

Ao  is  a  commonly  used  readiness  measure  for  weapon  systems,  and  this 
value  represents  the  percentage  of  weapon  systems  in  mission  capable  (MC)  status. 

number  of  MC  systems 

Ao  =  - 

total  number  of  systems 

According  to  the  fonnulas,  Ao  is  only  alterable  by  changing  the  MTBM 
and  MDT  that  addresses  the  reliability  of  the  system  before  it  breaks  and  in  terms  of  the 
maintenance  effort,  which  is  the  time  needed  for  maintenance  (MDT).  Maintenance  itself 
must  be  distinguished  in  terms  of  scheduled  and  unscheduled  maintenance.  Scheduled 
maintenance  includes  the  maintenance  activities  that  are  detennined  by  the  producer  of 
the  system  to  keep  a  system  safe  and  available.  Therefore,  the  data  about  scheduled 
maintenance  are  sensitive  to  the  LCC  analysis  and  are  valuable.  They  enable  us  to 
analyze  one  of  the  most  important  drivers  related  to  availability  and  cost.  Unscheduled 
maintenance  is  a  reliability  issue  of  a  system.  Concerning  our  second  proposed 
alternative,  the  reliability  data  can  be  filtered  from  the  maintenance  log  files.  Our  first 
alternative  uses  many  major  components  and  parts  from  the  second  alternative  solution, 
including  the  gearboxes,  rotor-head,  rotor-blades,  landing-gear,  etc.  Thus,  reliability  data 
can  be  derived  from  the  maintenance  log  files  and  analyzed  for  this  solution  also.  The 
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reliability  of  our  third  proposed  solution  must  be  calculated  based  on  the  reliability  data 
of  parts  and  components  with  respect  to  its  functional  and  physical  architecture. 

Maintainability  is  a  basic  need  requirement  and  is  indirectly  specified 
within  the  operational  availability  of  85%.  Actually,  that  specification  does  not  specify 
the  reliability  and  maintainability  itself.  Maintainability  is  dependent  on  the  level  of 
supply,  which  is  indirectly  specified  through  the  availability  rate  and  requirement  that  a 
certain  level  of  the  supply  must  be  stored  on  the  organic  ship. 

To  cover  all  these  hardware  and  software  maintenance  issues,  a  logistic 
concept  is  required  to  analyze  costs  when  the  system  is  embarked  and  also  when  land 
based.  The  logistic  concept  should  be  part  of  an  operational  concept  which  must  be 
refined  and  adapted  for  each  alternative  solution  from  the  basic  operational  concept 
already  developed  during  the  FFF-phase.  The  logistic  concept  determines  many  of  the 
O&S  cost  drivers,  like  the  way  of  maintenance  and  supply,  determines  the  required 
personnel,  facilities,  spare-part  level,  training,  and  some  more  concerns. 

It  can  be  summarized  that  experienced  LCC  analysis  personnel  are 
required  to  understand  the  complex  interactions  and  connections  of  the  life-cycle  theory 
and  its  construct  to  conduct  a  comprehensive  and  useful  LCC  analysis.  That  requires  the 
effort  and  support  from  producers,  military  and  civil  departments  of  the  Gennan  anned 
forces  to  generate  and  deliver  these  data.  Additionally,  only  when  a  logistic  concept 
exists,  then,  according  to  that  concept,  the  LCC  analyst  is  able  to  determine  the 
composition  and  proportion  of  each  of  the  logistic  cost  drivers  and  to  present  correct  and 
valuable  life-cycle  cost  calculations  for  each  alternative  to  enable  the  IPT  to  compare  the 
costs  of  the  alternative  systems  to  their  effectiveness. 

d.  Risk  Management 

Risk  management  in  defense  acquisition  and  procurement  plays  an  even 
more  critical  role  than  it  does  in  commercial  projects  according  to  Allen  (2008).  Risk  is 
defined  as  an  uncertain  event  or  condition  that,  if  it  occurs,  has  had  positive  or  negative 
effect  on  the  projects  objectives.  Furthermore  he  notes  that  the  U.S.  DoD  defines  risk  as  a 
measure  of  future  uncertainties  in  achieving  perfonnance,  schedule  and  cost  goals. 
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Military  weapons  systems  are  one  of  the  most  complex  and  sophisticated  products  which 
require  large  sums  of  tax  payer  money.  Risk  management  is  conducted  through  the 
programs  life-cycle,  and  one  of  the  PM’s  major  concerns  is  to  achieve  that  the  program 
within  cost,  schedule,  and  performance.  As  Blanchard  and  Fabrycky  (2011)  note,  risk 
management  consists  of  four  basic  categories.  These  are  technical  risk,  cost  risk,  schedule 
risk  and  programmatic  risk.  Furthermore,  they  explain  that  the  potential  risk  becomes 
increasingly  greater  as  complexity  and  new  technologies  are  introduced  in  the  design  of 
systems,  and  as  the  number  of  program  suppliers  increases  through  outsourcing.  That  is 
especially  true  for  many  major  weapon  systems  programs  due  to  the  political  requirement 
to  involve  many  national  companies.  Figure  63  depicts  the  relationship  between  the  four 
basic  risk  categories  according  to  the  INCOSE  handbook  (Haskins,  Forsberg,  Krueger, 
2010). 

Risk  involves  three  elements.  Allen  (2008)  explains  that  these  are  a  future 
event,  the  probability  of  that  the  future  event  occurring,  and  the  consequence  of  that 
future  event  occurrence  on  the  program’s  cost,  schedule,  and  performance  objectives. 


Figure  63.  Relationship  between  risk  categories. 

Furthermore,  Allen  (2008)  states  that  in  the  context  of  program 
management  the  level  of  risk  is  the  highest  in  the  beginning  of  the  program  and  decrease 


130 


as  it  progresses  to  completion  (Figure  64).  Therefore,  an  early  risk  management  is  vital  in 
a  military  program. 


Need 

Approval 


Approval  to 
Enter  Preliminary 
Design 
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Enter  Detailed 
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Approval  to 
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Production 


Figure  64.  Risk  and  program  life-cycle  relationship  according  to  Allen  (2008). 

Risk  management  contains  five  basic  steps  and  is  considered  an  iterative 

process: 

•  Risk  identification 

•  Risk  analysis 

•  Risk  mitigation  planning 

•  Risk  mitigation  implementation 

•  Risk  tracking 

The  following  risk  management  process  model  (Figure  65)  according  to 
US  DoD  PM  Tool  Kit  illustrates  this  iterative  process  (Under  Secretary  of  Defense 
(AT&L),  2009). 
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Figure  65.  US  DoD  Risk  management  process  model. 


Risk  planning  includes  the  development  of  a  risk  management  plan,  which 
should  be  part  of  the  systems  engineering  master  plan.  Risk  identification  includes  the 
screening  of  the  all  requirements  and  those  which  are  not  likely  to  be  met.  Risk 
assessment  concerns  the  determination  of  the  probability  not  to  meet  a  specified 
requirement,  and  risk  analysis  determines  the  way  in  which  the  risk  can  be  eliminated  or 
minimized.  At  least,  risk  handling  includes  all  activities  associated  to  change  or  modify 
the  process  and  later  the  system  (Blanchard,  Fabrycky,  2011). 

With  respect  to  the  ASW  need  and  the  current  stage  of  the  process  phase, 
the  problem  of  all  the  so  far  gained  data  about  costs  and  perfonnance  of  the  alternative 
systems  is  the  level  of  uncertainty.  Many  of  these  data  are  based  on  estimations,  results 
from  modeling  and  simulation,  or  just  promises  from  the  producer.  Some  of  the  data 
might  be  precise,  others  might  be  off  by  up  to  50%,  and  some  are  completely  wrong.  That 
problem  must  be  addressed  by  the  IPT  through  reflecting  risk.  The  risk  areas  of  the 
alternative  solutions  should  be  identified.  In  particular  the  technology  readiness  levels 
(TRL)  of  the  proposed  solutions  should  be  identified,  assessed,  and  analyzed  as  a  major 
matter  of  consideration  of  the  selection  process  of  an  alternative  solution.  Information 
and  data  delivered  from  the  contractors  and  studies  should  enable  the  IPT  to  conduct 
these  steps.  Figure  66  is  an  example  of  TRL  assessment  conducted  on  the  ASW  need 
related  to  some  of  the  KPPs. 
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Figure  66.  TRL  in  respect  to  some  of  the  KPPs  of  the  ASW  need. 


Figure  67  includes  a  risk  matrix  and  explains  the  risk  event,  likelihood  of 
the  event,  and  consequence  level.  This  way  of  conducting  and  illustrating  is  proposed  by 
the  U.S.  DoD  risk  management  guide  for  acquisitions  (Under  Secretary  of  Defense 
(AT&L),  2006).  The  likelihood  and  consequence  levels  are  already  detennined  by  the 
risk  management  guide.  The  users  of  this  tool  need  to  compare  the  identified  risk  areas 
with  the  definitions.  A  conducted  risk  assessment  with  respect  to  some  possible  risk  areas 
of  our  third  alternative  solution  is  shown  in  Figure  68.  It  must  be  applied,  of  course,  for 
all  three  alternatives  to  get  comprehensive  understanding  of  their  risk  areas  and  the 
likelihood  and  consequences. 
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# 

Risk  Event 

(Future  Root  Cause) 

Likelihood  Level* 

Consequence  Level* 

Cons 

Type 

Risk 

Rating 

Planned  Mitigation 
(what,  when,  who,  funding) 

1 

Aerial  system  will  not  meet 
requirement  for  take-offflanding 
up  to  sea  state 

2)  Low  likely  because  US 

Navy  UAS  have  already 
proven  technical  feasibility 

(5)  Cannot  meet  KPP. 
has  impact  on 
performance,  schedule 
and  cost  due  to  more 
development  efforts 

Perf., 

cost. 

schedule 

Mod 

Assume  Risk;  plan  for 
consequence,  focus  on  design 
and  interoperability  with  organic 
ship,  reduce  KPP  from  sea  state 

6  to  5 

2 

Failure  to  establish  sonar  data 
transfer  and  processing  from 
ship  to  aerial  system  and  vice 
versa  (using  ships  sonar  data 
processing  and  management 
capability). 

(3)  Likely  due  to  involvement 
of  two  systems  in  hard  and 
software  development 

(5)  Will  jeopardize 
program,  project 
cancellation 

Perf. 

Sev 

Control  Risk;  Make  hard  and 
software  development  a  high 
priority  to  ensure  earlier 
development,  add  more  senior 
programmers  and  frequent 
reviews 

3 

Aerial  system  will  not  meet 
endurance  performance 

(1 )  Not  likely  because  similar 
UAS  have  already  proven 
much  better  endurance  than 
KPP 

(5)  Cannot  meet  KPP. 
has  impact  on 
performance,  schedule 
and  cost  due  to  more 
development  efforts 

Perf., 

cost, 

schedule 

Mod 

Mitigate  Risk;  ensure  thorough 
data  collection  to  identify  and 
correct  sources  of  problems  TD 

4 

Aerial  system  cannot  perform 
sonar  dipping  KPP 

(3)  Likely  due  to  integration 
of  an  automated  dipping 
sonar  and  unknown 
autonomous  hover 
performance 

(5)  Will  jeopardize 
program,  project 
cancellation 

Perf. 

Sev 

Control  Risk;  Make  hard  and 
software  development  a  high 
priority  to  ensure  earlier 
development,  add  more  senior 
programmers  and  frequent 
reviews 

Figure  67.  Risk  assessment  applied  matrix  according  to  risk  management  guide. 


Consequence  Levels/Types 


Level 

Technical 

Performance 

Schedule 

Cost 

1 

Minimal  or 
no  impact 

Minimal  or 
no  impact 

Minimal  or 
no  impact 

2 

Minor  reduction;  little  or 
no  impact  on  program 

Able  to  meet  key 
dates 

Budget  or  unit 
production  cost 
increase  of  <1% 

3 

Moderate  reduction; 
limited  impact  on 
program  objectives 

Minor  Schedule 
slip;  able  to  meet 
key  MS  /  no  float 

Budget  or  unit 
production  cost 
increase  of  <5% 

4 

Significant  degradation; 
may  jeopardize  program 
success 

Program  critical 
path  affected;  MS 
slip<6  months 

Budget  or  unit 
production  cost 
increase  of  <10% 

5 

Severe  degradation; 
cannot  meet  KPP;  will 
jeopardize  program 

Cannot  meet  key 
program  MS;  MS 
slip>  6  months 

Exceeds  APB 
threshold  of 
>10% 

Likelihood  Levels 


Level 

Likelihood 

Probability  of 
Occurrence 

1 

Not  Likely 

~  10% 

2 

Low  Likelihood 

~30% 

3 

Likely 

~  50% 

4 

Highly  Likely 

~70% 

5 

Near  Certainty 

~90% 

Figure  68.  Consequence  and  likelihood  levels  according  to  risk  management  guide  for  DoD 

acquisition  (Under  Secretary  of  Defense  (AT&L),  2006). 
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Another,  additional  way  to  address  the  uncertainty  and  the  robustness  of 
the  information  is  to  conduct  a  sensitivity  analysis.  There  is  almost  no  true  and  correct 
data  without  testing.  The  data  and  information  are  used  in  the  AoA  process  are  the  most 
plausible  etsimates  to  cover  the  uncertainties  in  the  knowledge.  The  purpose  of  the 
sensitive  analysisis  to  acknowledge  the  underyling  uncertainty,  and  it  should  convey  how 
sensitive  predicted  benefits  of  the  alternatives  are  to  change  in  assumptions  (Boardman, 
2011).  Generally,  three  basic  approaches  exist  to  doing  sensitivity  analysis.  These  are  the 
partial  sensivity  anlysis,  the  worst-  and  best-case  analysis,  and  the  Monte  Carlo  sensivity 
analysis.  With  respect  to  the  IPT‘s  capabilities  and  knowledge,  only  the  worst-best-case 
analysis  is  applicable.  In  particular  the  Monte  Carlo  simulation  and  analysis  requires 
specialist  which  are  not  usually  availbaly  in  a  acquistion  program  office  or  even  in  the 
department.  Therefore,  analysis  on  the  level  of  Monte  Carlo  analysis  should  be  contracted 
to  specialized  reseachers.  In  contrary,  the  worse-best-case  analysis  is  within  the  spectrum 
of  an  IPT  and  is  a  tool  which  can  and  should  be  applied  to  understand  the  uncertanties 
and  the  possible  negative  or  positive  impact  on  the  different  solutions. 

e.  Cost  Benefit  Analysis 

Cost  benefit  analysis  can  be  distinguished  in  two  major  types,  that  are  the 
“ex  ante  CBA”  and  the  “ex  post  CBA”.  ”Ex  ante  CBA”  is  the  commonly  used  CBA.  It  is 
conducted  during  a  stage  of  a  project  is  under  consideration  an  assist  in  the  decision 
about  whether  are  sources  should  be  allocated  or  not  (Boardman,  2011).  CBA  is  a 
framework  for  measuring  efficiency  therefore  all  cost  must  be  identified  and  allocated. 
According  to,  Boardman,  Greenberg,  Vining,  and  Weimar  (2011)  the  process  of 
conducting  CBA  can  be  supported  by  breaking  that  process  down  in  nine  basic  steps. 

1 .  Specify  the  set  of  alternatives. 

2.  Decide  whose  benefits  and  costs  count. 

3.  Identify  the  impact  categories,  catalogue  them,  and  select 
measurement  indicators 

4.  Predict  the  impacts  quantitatively  over  the  life-cycle. 

5.  Monetize  (  attach  a  currency  to)  all  impacts 

6.  Discount  benefits  and  costs  to  obtain  present  values. 

7.  Compute  the  net  present  value  of  each  alternative. 

8.  Perfonn  a  sensitivity  analysis. 

9.  Make  a  recommendation. 
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The  AoA  process  of  the  ASW  need  meets  the  “ex  ante  CBS”  definition 
and  is  also  true  for  most  likely  all  governmental  projects.  However,  CBA  is  only  useful 
for  military  projects  similar  to  many  civil  projects  where  efficiency  is  in  focus,  like 
support  contracts  for  typical  homeland  services  (cleaning  barracks,  food... etc.). 
Nevertheless,  the  nine  steps  shown  here  are  basically  valid  and  useful  for  conducting 
acquisition  processes  concerning  weapon  systems.  Steps  one  to  seven  have  already  been 
conducted  in  this  thesis.  So,  the  basic  CBA  theory  emphasizes  the  methods  used  thus  far 
to  perform  the  processes  to  select  a  system  for  the  need. 


f  Cost  Effectiveness  Analysis 

In  military  acquisition  processes  related  to  weapon  systems  the  cost- 
effectiveness  analysis  (CEA)  is  the  generally  used  method  because  often  not  all  impact 
areas  of  a  project  can  be  monetized,  like  the  life  of  a  soldier  or  the  success  of  a  military 
operation.  Cost  effectiveness  (CE)  compares  alternatives  in  terms  of  the  ratio  of  their 
costs  and  an  effectiveness  measure  (Figure  69).  The  costs  of  the  three  alternative  ASW 
systems  should  have  already  been  detennined  as  explained  before,  and  also  the  measure 
of  the  performances,  effectiveness,  and  weights  of  each  system  are  known.  CE  is  a 
composite  measure  of  cost  (input)  to  effectiveness  (output). 


Measures  of 

Effectiveness 

(attributes) 


Preferences  for 
Individual  Attributes 
(value  functions) 


EFFECTIVENESS 

(MOE) 


Relative 
Importance  of 
the  Attributes 
(weights) 


Figure  69.  Cost  effectiveness  model  according  to  Hansen  (2012). 
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Military  acquisition  is  about  an  alternative  that  combines  maximized 
effectiveness  at  minimized  cost.  Cost-effectiveness  is  an  indicator  of  how  well  the 
alternative  does  in  these  two  attributes.  It’s  useful  to  think  about  CE  in  two  axis  space  of 
dominance  and  effectiveness  and  to  depict  it  accordingly  in  graph. 


Figure  70.  Cost  effectiveness  graph. 

A  sample  graph  of  cost  and  effectiveness  of  the  three  alternatives  is  shown 
in  Figure  70.  Our  second  alternative  would  be  a  superior  and  efficient  solution  in  contrast 
to  our  first  alternative,  but  our  third  alternative  shows  the  highest  effectiveness  and 
highest  cost.  In  their  final  report,  the  IPT  should  present  all  pros  and  cons  of  all 
alternatives  and  also  what  is  the  optimal  solution,  in  particular  when  the  funding  is  a 
serious  constraint.  An  optimal  solution  is  a  solution  that  is  efficient  in  respect  to  its  costs 
and  has  nevertheless  an  acceptable  effectiveness.  According  to  the  graph  in  Figure  71, 
that  solution  would  be  our  second  alternative.  Defining  optimal  solutions  means  also 
conducting  a  trade-off  analysis  with  respect  to  the  performance  or  weights.  If  money  is 
no  constraint  because  all  alternative  systems  are  within  the  possible  program  funding, 
then  our  third  alternative  should  be  presented  as  primary  solution.  At  least  the  IPT 
presents  only  the  alternatives  related  to  perfonnance,  risks,  costs,  and  trade-offs  because 
the  decision  maker  selects  the  alternative  system  that  will  become  the  future  ASW  system 
to  fill  the  Navy’s  gap. 
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5.  Summary  and  Conclusion 

The  CPM  requests  a  study  and  proposal  of  alternative  solutions  which  will  consist 
of  a  market  available  one,  a  possible  improvement  of  in-service  systems,  and  also  of  a 
newly  developed  system.  The  chapter  presented  systems  engineering  methodologies  and 
tools  that  enable  us  to  refine  the  previously  established  infonnation  and  knowledge  of  the 
need,  and  to  support  the  identification  of  a  physical  solution  in  accordance  to  the  CPM. 
Through  conducting  a  system-design  synthesis  with  a  system-architecture  some 
alternative  solutions  could  be  found  and  analyzed.  Even  when  the  alternatives  and  their 
data  are  not  fully  researched  and  designed,  the  illustrated  alternatives  could  fit  basically 
into  the  ASW-need  requirements.  The  following  process  of  analyzing  alternatives  is  an 
analytical  comparison  of  the  operational  effectiveness,  suitability,  and  life-cycle  cost  (or 
total  ownership  cost)  that  shall  satisfy  the  reasoned  capability  needs  and  fill  the  gap.  The 
goal  of  AoA  is  to  examine  potential  materiel  solutions  and  in  a  second  step  to  identify  the 
most  promising  option  and  to  present  the  infonnation  in  the  final  report  for  the  decision 
makers.  The  IPT  needs  to  develop  the  evaluation  measures  to  detennine  the  performance 
of  components  and  the  effectiveness  of  the  system,  and  they  need  to  conduct  a 
comprehensive  life-cycle  cost  analysis.  That  enables  to  conduct  an  effectiveness  to  cost 
analysis  that  supports  the  decision  makers  to  find  the  right  system. 
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VI.  CONCLUSION,  RECOMMENDATIONS  AND  AREAS  FOR 

FURTHER  RESEARCH 


The  objective  of  this  thesis  was  to  examine  the  Gennan  basic  acquisition 
guidelines  and  to  examine  and  apply  systems  engineering  methodologies  and  tools  to  the 
CPM.  Our  objective  was  to  show  where  and  how  the  methodologies  and  tools  lit  into  the 
CPM’s  list  of  deliverables.  Furthermore,  a  basic  systems  engineering  process  was 
conducted  with  respect  to  a  possible  next- generation,  ship-borne  ASW-system  for  the 
Gennan  Navy.  The  purpose  of  this  application  was  to  demonstrate  the  methodologies  and 
tools  on  a  realistic  case  common  in  military  acquisition  on  a  basic  level.  Also  this  thesis 
sought  to  clarify  the  basic  problem  of  a  possible  need  of  a  next-generation,  ship-bome 
ASW  system  for  the  German  Navy’s  ASW  ships. 

The  current  Gennan  Defense  Guidelines  define  the  role  of  the  Gennan  Anned 
Forces  in  accordance  with  cunent  and  likely  future  threats.  Similarly,  their  capabilities 
will  be  adapted  with  respect  to  the  new  missions  and  tasks.  The  variation  and  number  of 
needed  capabilities  underlie  the  likelihood  of  risk,  threat,  and  funding.  ASW  missions 
cunently  are  no  longer  considered  a  primary  capability  of  the  Gennan  Navy.  The  unique 
configuration  and  flight  features  to  operate  from  small  ships  and  to  deploy  a  dipping 
sonar  makes  an  ASW  helicopter  the  only  weapon  system  worldwide  which  can  deliver 
this  kind  of  anti-submarine  capability  as  a  very  important  defense  contribution  to  a  fleet. 
The  new  military  situation  requires  multi-role  helicopters  for  all  kinds  of  missions.  These 
state-of-the-art  multi-mission  helicopters  are  meanwhile  too  large  to  be  embarked  and 
operated  from  older  and  smaller  ASW  capable  ships,  like  the  FI 23.  The  ASW  ships  in 
service  cannot  accommodate  the  future  ASW  helicopter  (MH90)  due  to  their  limited 
hangar  space.  This  limitation  will  cause  the  loss  of  the  ship’s  important  aerial  ASW 
sensor  and  weapon. 

The  most  important  current  guideline,  the  CPM,  regulates  the  principal  steps 
within  an  acquisition  program,  the  responsibilities  between  departments  as  well  as 
between  the  forces  and  the  BAAINBw.  The  CPM  is  a  MoD  internal  guideline  concerning 
the  need-investigation,  need-cover,  and  utilization/in-service  support  processes  of  any 

139 


weapon  systems  in  the  German  Armed  Forces.  As  soon  as  a  materiel  solution  is 
detennined  by  the  PlgABw  and  approved  by  the  MoD  for  cases  with  high  priority,  the 
PlgABw  tasks  an  IPT  to  conduct  the  FFF  process  and  to  present  an  FFF-document  that 
explains  the  capability  gap  and  determines  a  need.  After  the  FFF  is  approved  by  the  Chief 
of  Federal  Armed  Forces  Staff,  the  leadership  of  a  program  changes  from  PlgABw  to  the 
BAAINBw,  which  has  to  develop  at  least  three  alternative  solutions  according  to  the  FFF 
functional  requirements.  This  is  the  second  part  of  the  analysis  process  that  presents  the 
actual  initiation  of  a  procurement  program 

The  ASW  is  a  good  example  that  allows  us  to  go  through  all  necessary  and 
recommended  steps  of  the  CPM  and  to  apply  systems  engineering  methodologies  and 
tools.  This  example,  as  examined  in  this  thesis,  is  useful  for  the  tasked  IPT  to  research  the 
problem  and  to  deliver  the  required  CPM’s  phase  documents.  Many  of  the  CPM’s 
deliverables  such  as  formulating  needs,  writing  requirements,  and  conducting  analyses 
comes  from  the  IPT,  which  consists  of  military  personnel  to  support  the  acquisition 
processes  within  the  civil  procurement  agency  at  all  levels.  The  typical  Gennan  service 
member  is  usually  unfamiliar  with  the  well-known  methodologies  and  tools  applicable  in 
project  and  program  management.  Additionally,  no  U.S.  DoD  5000  comparable  series 
exists  that  could  support  the  work  of  the  acquisition  work  force  with  respect  to  feasible 
methodologies  and  tools  for  military  acquisition.  As  a  result  many  important  past 
acquisition  programs  have  not  been  successful. 

The  existing  tools  in  program  management  are  not  simply  derived  from  one  or 
two  research  disciplines;  rather  these  tools  come  from  a  wide  range  of  research  areas  of 
business  and  engineering.  Modeling,  supply-chain  management,  engineering,  decision 
making,  cost  benefit  analysis,  test  and  evaluation,  life-cycle  cost,  quality  management 
and  management  soft-skill  disciplines  are  just  some  of  the  contributing  disciplines.  This 
indispensable  knowledge  about  the  methodologies  and  tools  makes  program  management 
in  military  acquisition  a  comprehensive  and  complex  responsibility.  Systems  engineering 
is  already  a  proven  and  widely-used  method  for  handling  projects  in  industry.  Therefore, 
systems  engineering  should  be  a  crucial  area  of  knowledge  for  all  personnel  in  military 
acquisition  programs. 
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For  this  thesis,  the  accepted  steps  for  working  through  a  project  were  adapted  to 
the  guidelines  and  deliverables  of  the  CPM.  The  system  engineering  processes  in  Chapter 
IV  were  shown  to  be  an  applicable  method  in  the  FFF  Analysis  Phase  and  helped  to 
illuminate  the  ASW  capability  need  thoroughly.  The  processes  enabled  us  to  identify  and 
understand  the  “wants  and  needs”  of  the  stakeholders,  and  also  to  identify  and  to  select 
the  most  important  needs.  Additionally,  the  determination  of  boundaries  and  top-level 
functions  allowed  us  to  redefine  the  problem  statement.  Finally,  an  effective  need  could 
be  developed  from  the  early  primitive  need  that  enables  the  IPT  to  understand  the  true 
nature  of  the  need.  With  all  this  information,  the  design  alternatives  could  be  limited  to 
an  aerial  system,  and  its  basic  functional  requirements  could  be  derived.  The  life-cycle 
cost  estimation  was  the  last  step  examined  that  should  enable  an  IPT  to  present  a  sound 
FFF  document. 

The  applied  systems  engineering  process  in  Chapter  V  supported  the 
identification  of  the  functions  and  physical  components  and  their  allocation.  It  also 
supports  this  view  within  a  system  of  systems.  The  ASW  need  system  can  also  consist  of 
several  systems  which  are  de-located  and  operated  by  several  systems  in  a  “system  of 
systems.”  By  conducting  a  system-design  and  system-architecture  synthesis  some 
alternative  solutions  could  be  found  and  analyzed.  The  systems  engineering  process 
presented  led  to  three  possible  solutions  in  accordance  with  the  CPM  requirements.  An 
additional  solution  which  could  support  the  system  of  systems  approach  was  also 
proposed  that  could  increase  the  endurance  performance  of  the  three  aerial  alternative 
solutions.  Although  the  alternatives  and  their  data  have  not  been  researched  and  designed, 
they  appear  to  meet  the  stated  ASW-need  requirements.  The  process  of  analyzing 
alternatives  presented  here  is  an  analytical  comparison  of  the  operational  effectiveness, 
suitability,  and  life-cycle  cost  (or  total  ownership  cost)  that  will  satisfy  the  reasoned 
capability  needs  and  fill  the  gap.  The  main  objective  of  conducting  an  AoA  process  is  to 
examine  potential  materiel  solutions,  and  in  a  secondary  objective  is  to  identify  the  most 
promising  option.  The  process  that  was  partially  applied  in  this  thesis  should  support  the 
IPT  in  producing  and  presenting  the  previously  gathered  infonnation  in  a  final  report  in 
accordance  with  the  requirements  of  the  CPM. 
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No  military  program  is  entirely  equivalent  to  another.  Therefore,  military 
acquisition  needs  to  be  flexible.  It  must  adapt  methodologies  and  tools  to  determine 
solutions  for  problems,  such  as  capability  gaps.  Methodologies  and  tools  of  systems 
engineering  allow  for  establishing  a  flexible  analysis  process  for  military  acquisition 
programs  that  is  in  compliance  with  the  new  German  Anned  Forces  acquisition  and 
procurement  guidelines.  This  enables  the  involved  personnel,  like  the  IPTs,  to  adapt  the 
methods  and  tools  to  the  different  demands  and  conditions  of  a  program,  and  to  establish 
a  systems  engineering  design  process  pertinent  to  a  specific  problem,  as  this  thesis 
proved.  The  U.S.  DoD  already  recognizes  the  usefulness  of  systems  engineering 
methodologies  and  tools,  and  the  DoD  already  uses  these  tools  within  its  acquisition 
programs.  The  DoD  5000  series  gives  guidance  on  the  principal  application  of  these 
methods  within  programs.  The  Gennan  MoD  should  extend  its  guidelines  to  include 
current  knowledge  of  systems  engineering  and  to  educate  its  personnel  about  these 
methods. 

The  capability  gap  will  become  a  reality  in  the  near  future  if  the  ASW-capable 
ships  receive  no  redesign  and  construction  to  accommodate  the  new  multi-mission 
helicopters,  like  the  MH90.  It  depends,  of  course,  on  the  political  and  military  decision 
makers  to  decide  how  to  proceed  concerning  ASW  in  the  German  Navy.  However,  the 
research  and  analysis  on  ASW  has  shown  that  only  properly  equipped  and  compounded 
ASW  forces  can  be  successful  in  conducting  ASW  missions.  Assuming  that  ASW 
remains  a  primary  capability  in  the  German  Navy,  then  the  ASW  capable  ships  must  have 
a  new  aerial  ASW  system  which  should  show  improved  capabilities  over  the  current 
ASW  systems  in  terms  of  endurance  and  availability.  Multi-mission  helicopters  are 
always  a  compromise  to  accommodate  all  their  missions,  and  so,  they  are  necessarily 
limited.  Therefore,  only  ASW-specialized  systems  promise  an  increase  of  performance 
and  availability  that  might  also  reduce  costs.  A  highly  integrated  solution  in  a  system  of 
systems  should  be  preferred  in  ASW  because  it  opens  new  possibilities  for  increased 
performance  when  considered  against  the  background  of  different  aerial  and  surface 
assets.  The  German  ships  already  have  the  advantage  of  embarking  two  helicopters, 
which  opens  further  capability  composition  possibilities.  Multi-mission  helicopters  could 
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work  with  specialized  ASW  aerial  systems,  or  if  necessary,  two  ASW  systems  could 
work  together  to  increase  their  availability  and  effectiveness. 

This  thesis  could  only  conduct  a  study  on  a  basic  level  due  to  time  constraints  and 
a  lack  of  available  data.  That  leaves  room  for  more  research  in  respect  to  the  ASW 
problem  and  its  related  need.  In  particular  an  operational  study  on  the  Gennan  ASW 
issue  will  certainly  illuminate  the  problem  even  more  and  would  help  to  specify  the  need 
and  requirements  for  a  possible  solution.  Furthermore,  a  comprehensive  systems- 
engineering  process  could  be  conducted  to  deliver  real  data  solution  proposals  for  the 
ASW  problem.  Further  research  could  lead  to  the  implementation  of  improved 
managerial  methods  and  could  also  provide  an  expanded  view  of  managerial  and  decision 
maker  roles  and  activities  in  a  military  acquisition  program. 
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